ipcop-devel Mailing List for IPCop Firewall

Hello Héctor,


thanks for your report.


> Just a quick note running IPCop on Sparc. It’s been already a while since I
> installed IPCop on my Sparc machine and I’m a happy user now :-) It’s been
> running non-stop for 20 days with no problems. The build I’ve been testing
> is SVN 1959. IDS gave me some problems so I disabled it, in this new build I
> will try to find what happened to it if it’s still not working. VPN I
> haven’t been able to work with it, I will also try to set up a roadwarrior
> (windows) next week with the new build to test it out. If one of the
> developers is interested, I can set up a network so we can test out VPN from
> IPCop to IPCop, of course if it’s the right time to test it.

IPsec would be interesting to know.
Might still require some tweaking in the settings on the IPCop side 
though. So I guess that's not something for the faint of heart.

OpenVPN will not work as is. Haven't looked into that yet.

IDS is (more than) broken.


> I will make an update and build again this weekend so I can report on the
> current SVN, unless someone tells me not to. I’ve been following changes on
> SVN and the ulogd change seems very interesting to look at.

Achim is still tinkering with that, but would be interesting to just let 
ulogd run for a while and gather some data. Given enough SQL magic that 
will give some interesting stats and possibilities.


Olaf

-- 

A weizen a day helps keep the doctor away.

David W Studeman wrote:

>   Before I submit an rfe, would you folks consider this if I supply the 
> patches to rc.flash.up, the 386 kernel config and the mkflash file? The 
> latter would simply need the ramdisk not added to grub but you may want 
> to keep the no dma argument for folks that need it to be there.

I have some worries about upgrading existing mkflash'd installation.
These can have varying sizes ramdisks.

What happens if tmpfs is defined to be larger than available memory?
What happens if currently defined (and used) ramdisk is larger than the 
xx MB we would define for tmpfs?


Ideally we'd need to fetch the currently defined ramdisk size and use 
that for tmpfs size. Either looking in grub.conf or something like:
df -B 1M /dev/ramdisk | grep dev | awk '{print $2};'


>   Of course you all know this is the method in 1.9.3. I will submit an 
> rfe with patches if you think you would do this for 1.4.22, otherwise, I 
> won't clog the rfe list with it.

I don't think a working patch clogs our RFE list ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

Feature Requests item #2212546, was opened at 2008-10-31 20:37
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=2212546&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: kevross (kevross_33)
Assigned to: Nobody/Anonymous (nobody)
Summary: Snort Update to Rules Supported Version

Initial Comment:
Hey,

ipcop is using snort 2.6 which is no longer supported for Snort rules (aside from emerging threats of course ;p). 

There has been about 4 VRT rules updates since snort 2.6 became unsupported for VRT rule updates earlier this month. 

I would suggest a rule update to 2.8.X to limit having to update the engine anytime soon, provide new features and so on. 



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

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

Hello all:

 

Just a quick note running IPCop on Sparc. It’s been already a while since I
installed IPCop on my Sparc machine and I’m a happy user now :-) It’s been
running non-stop for 20 days with no problems. The build I’ve been testing
is SVN 1959. IDS gave me some problems so I disabled it, in this new build I
will try to find what happened to it if it’s still not working. VPN I
haven’t been able to work with it, I will also try to set up a roadwarrior
(windows) next week with the new build to test it out. If one of the
developers is interested, I can set up a network so we can test out VPN from
IPCop to IPCop, of course if it’s the right time to test it.

 

I will make an update and build again this weekend so I can report on the
current SVN, unless someone tells me not to. I’ve been following changes on
SVN and the ulogd change seems very interesting to look at.

 

Thanks to all for the great support on Sparc!

 

Hector Mendoza

 

08:30:41 up 20 days, 19:39,  0 users,  load average: 0.19, 0.08, 0.02

 

Linux bato 2.6.25 #1 SMP Wed Oct 8 16:14:00 GMT 2008 sparc64 GNU/Linux

 

Services running:

 

CRON server 2384 kB RUNNING 

DHCP Server / DNS proxy server 2184 kB RUNNING 

Intrusion Detection System (GREEN)   STOPPED 

Intrusion Detection System (RED)   STOPPED 

Kernel logging server 2968 kB RUNNING 

Logging server 2096 kB RUNNING 

NTP Server 5280 kB RUNNING 

Secure shell server 4600 kB RUNNING 

VPN   STOPPED 

Web proxy 17520 kB RUNNING 

Web server 7280 kB RUNNING

  Before I submit an rfe, would you folks consider this if I supply the 
patches to rc.flash.up, the 386 kernel config and the mkflash file? The 
latter would simply need the ramdisk not added to grub but you may want 
to keep the no dma argument for folks that need it to be there.

  Very few changes are needed and 1.4.22 has a kernel upgrade anyway. 
All that would need to be done is to simply change the following in 
kernel.config.i386 and kernel.config.i386.smp line:

# CONFIG_TMPFS is not set

To:

CONFIG_TMPFS=y

The rc.flash.up near the top would need to be changed from:

  umount -n /dev/ramdisk
mke2fs -b 1024 -m 0 /dev/ramdisk

rm -rf /tmp/
rm -rf /var/log
rm -rf /var/log/cache/

mount -n /dev/ramdisk /ram/
mkdir -p /ram/{log,squid,tmp}

To:

# Max amount of RAM used by the tmpfs mount can be set
# as a fixed size (eg 32M) or percentage (eg 50%). Default is 64M.
TMPFS_MAX_SIZE=64M

rm -rf /tmp/
rm -rf /var/log
rm -rf /var/log/cache/

mount -t tmpfs -o size=$TMPFS_MAX_SIZE tmpfs /ram
mkdir -p /ram/{log,squid,tmp}

And for the mkflash change, simply remove:

ramdisk_size=$ramdisk_KB in the grub section.

  Note that no changes to /etc/fstab are needed. I often see /dev/shm 
mounted as tmpfs in some cases. For mounting /ram as tmpfs it is totally 
unnecessary. In kernel documentation is very vague about this but after 
running it by folks who would definitely know, it was usually added to 
fstab only for convenience and to show people that as of kernel 2.4 it 
exists and can and should be used instead of the rd filesystem.

  Benefits by doing this are:

1. Does not need formatting.

2. Can be remounted at a different size with no data loss. For example, 
a 64MB /ram directory is not large enough for the latest snort download 
and update. I was able to do this with repeatable results:

mount -o remount -t tmpfs -o size=30% tmpfs /ram

Or:

mount -o remount -t tmpfs -o size=128MB tmpfs /ram

With no data loss whatsoever.

3. Does not really apply how we use it but the tmpfs would use swap if 
needed but IPCop flash installs do not use swap to save the flash device 
from imploding from too many writes.

  Of course you all know this is the method in 1.9.3. I will submit an 
rfe with patches if you think you would do this for 1.4.22, otherwise, I 
won't clog the rfe list with it.

Eric Oberlander wrote:
> On Sat, Oct 18, 2008 at 9:30 AM, SourceForge.net
> <no...@so...>  wrote:
>> Bugs item #2176286, was opened at 2008-10-18 01:30
>> 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=2176286&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.21
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: David W Studeman (Davesworld) (davews)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: Proxy access.log permissions on flash installs
>>
>> Initial Comment:
>> When creating a flash image with the latest mkflash script, /var/log/squid/access.log does not exist upon booting a new flash image and is not created by the touch command in rc.flash.up. It is created when one activates the proxy log in the web gui and the resultant mode is 640 not 644. Since the file is one of the files that get compressed with rc.flash.down and if it exists there already, it is left intact with the same mode it was saved in. This patch in the mkflash script completely solves the problem and upon first boot, the access.log file exists properly as mode 644 squid:squid so if the proxy is activated and log enabled, it is readily readable by the web gui with no manual intervention.
>>
>> Also note as per Eric Oberlander, prior to this solution, by deleting the /var/log/squid directory and rebooting, the proper file and mode are there, in the absense of this directory, rc.flash.up will touch properly since sysinit runs with a umask of 022. The changes to mkflash in the below preclude the need to do any of this.
>>
>> Dave Studeman
>
> Hi David
>
> To clarify something that's bugging me, I think you said in the
> previous thread that the 1.9,3 mkflash script works OK, but the 1,4,X
> version does not.
>
> I don't see a huge difference between the two scripts, so why do we
> need to patch one and not the other?
>
> Eric
>

  Your change that you committed to 1.9.3 is definitely the right one 
and does not harm the existing access.log in any way. I think what threw 
me off about the rc.flash.up scripts in both IPCop generations is that 
it would skip over /var/log/squid if the directory is there and not 
touch the access.log. Moving it outside the "if" loop makes it work 
every time.

Hopefully, your changes will make it to 1.4.22 as well. Thanks Eric!

-- 
Dave Studeman
http://www.raqcop.com

----- Original Message ----- 
From: Davide
To: ipc...@li...
Sent: Monday, October 27, 2008 7:53 PM
Subject: [IPCop-devel] Adding vm-tools package to IPCOP 1.4.21


> make[3]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'

I am stopped before that stage.
I add the call in make.sh after openvpn
On the lfs file, I had to add --with-kernel-release=$(KVER) or configure
stop very early

Tested with 2008.09.03-114782 or 2008.10.10-123053 , it fail similary with
make[3]: Entering directory
`/usr/src/open-vm-tools-2008.09.03-114782/modules/linux/vmxnet'
In file included from /lib/modules/2.4.36/build/include/asm/dma.h:14,
                 from vmxnet.c:34:
/lib/modules/2.4.36/build/include/linux/delay.h:62: error: parse error
before "const"
make[3]: *** [vmxnet.o] Error 1

Gilles

PS I have attached the lfs file I used

 Hello, 
 
 i'd build ipcop 1.9.3 svn 2023 and tried to install it via CD ISO Image.
 After partitioning the disk i receive "tar error" and ipcop restarts the computer.
 The error messages in the console are:
 
 Running command: /bin/mount -o ro /dev/sr0 /cdrom
 FYI (- i forgotten text)
 Error in ped_disk_commit disksize
 
 other console:
 1+0 records in 
 0+0 records out
 input/output error during read on /dev/sda
 inpur/output error during wirte on /dev/sda
 
 The hard disk is a maxtor ide 6Y080L0. 
 i also have the same problem with a serial ata hard disk connected to this board.
 The disks are healthy.
 
 Is this because the ipcop 1.9.3 is still "too young" or did i found a bug? Do you need more information?
 
 Thomas Brinkmann

Robert Kerr wrote:
> On Sat, 2008-10-11 at 01:35 +0200, Gilles Espinasse wrote:
> 
>>> - cd $(DIR_APP) && sed -i -e 's@#MD5_CRYPT_ENAB.no@MD5_CRYPT_ENAB yes@' \
>>> + # Use the more secure MD5 encryption method
>>> + cd $(DIR_APP) && sed -i -e 's@#ENCRYPT_METHOD DES@ENCRYPT_METHOD MD5@' \
>>>   -e 's@/var/spool/mail@/var/mail@' etc/login.defs
> 
>> Greg Schafer has suggested on DYI to enable more secure SHA512 instead of
>> MD5
>> http://www.diy-linux.org/pipermail/diy-linux-dev/2008-October/001309.html
> 
>> As we have glibc-2.7, I think we should do that.
>> Opinion?
> 
> Certainly it makes sense for a security perspective - my only concern
> would be to make sure it gets tested on some older hardware before
> release. On modern hardware you're probably only talking microseconds,
> on a P90 it may make a visible difference to login time.

I tried this on a Pentium/133 the other day. Login showed no noticeable 
difference to me.
Will try to make some accurate measurements.


Olaf

-- 

A weizen a day helps keep the doctor away.

Hi!
I'm trying to install vm-tools in Ipcop 1.4.21 distribution following these
instructions:
http://www.ipcop.org/index.php?module=pnWikka&tag=HowToCompileAdditionalCode

I've downloaded the sources package of ipcop and compile it with success.
So,
I've added the source package of open-vm-tools (
http://open-vm-tools.sourceforge.net/) at directory "cache".
I've write the script for open-vm-tools in "lsf" directory, like this:

$(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
    @$(PREBUILD)
    @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
    cd $(DIR_APP) && ./configure --without-x --without-procps --without-dnet
--without-icu
    cd $(DIR_APP) && make
    cd $(DIR_APP) && make install
    @rm -rf $(DIR_APP)
    @$(POSTBUILD)

But, i have this trouble with the make command:

make[3]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
make[4]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
Dependencies for .././linux/af_vsock.c
Dependencies for .././linux/vsockAddr.c
Dependencies for .././linux/util.c
Dependencies for .././linux/driverLog.c
make[4]: Leaving directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
make[4]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
Compiling .././linux/af_vsock.c
../linux/af_vsock.c: In function `VSockVmciStreamConnect':
../linux/af_vsock.c:3199: warning: implicit declaration of function
`DEFINE_WAIT'
../linux/af_vsock.c:3199: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c:3199: error: (Each undeclared identifier is reported
only once
../linux/af_vsock.c:3199: error: for each function it appears in.)
../linux/af_vsock.c:3275: warning: implicit declaration of function
`prepare_to_wait'
../linux/af_vsock.c:3310: warning: implicit declaration of function
`finish_wait'
../linux/af_vsock.c: In function `VSockVmciAccept':
../linux/af_vsock.c:3348: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c: In function `VSockVmciStreamSendmsg':
../linux/af_vsock.c:4079: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg':
../linux/af_vsock.c:4428: error: `wait' undeclared (first use in this
function)
make[4]: *** [af_vsock.o] Error 1
make[4]: Leaving directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
make[3]: *** [driver] Error 2
make[3]: Leaving directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
make[2]: *** [vsock] Error 2
make[2]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782'
make: *** [/usr/src/log/vm-tools-2008.09.03-114782] Error 2

Someone have any idea?
(I run compile with some parameters that exclude some (optional ?) librarys)

Sorry for my english :-\

Best regards.
Davide

Hi!
I'm trying to install vm-tools in Ipcop 1.4.21 distribution following these
instructions:
http://www.ipcop.org/index.php?module=pnWikka&tag=HowToCompileAdditionalCode

I've downloaded the sources package of ipcop and compile it with success.
So,
I've added the source package of open-vm-tools (
http://open-vm-tools.sourceforge.net/) at directory "cache".
I've write the script for open-vm-tools in "lsf" directory, like this:

$(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
    @$(PREBUILD)
    @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
    cd $(DIR_APP) && ./configure --without-x --without-procps --without-dnet
--without-icu
    cd $(DIR_APP) && make
    cd $(DIR_APP) && make install
    @rm -rf $(DIR_APP)
    @$(POSTBUILD)

But, i have this trouble with the make command:

make[3]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
make[4]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
Dependencies for .././linux/af_vsock.c
Dependencies for .././linux/vsockAddr.c
Dependencies for .././linux/util.c
Dependencies for .././linux/driverLog.c
make[4]: Leaving directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
make[4]: Entering directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
Compiling .././linux/af_vsock.c
../linux/af_vsock.c: In function `VSockVmciStreamConnect':
../linux/af_vsock.c:3199: warning: implicit declaration of function
`DEFINE_WAIT'
../linux/af_vsock.c:3199: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c:3199: error: (Each undeclared identifier is reported
only once
../linux/af_vsock.c:3199: error: for each function it appears in.)
../linux/af_vsock.c:3275: warning: implicit declaration of function
`prepare_to_wait'
../linux/af_vsock.c:3310: warning: implicit declaration of function
`finish_wait'
../linux/af_vsock.c: In function `VSockVmciAccept':
../linux/af_vsock.c:3348: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c: In function `VSockVmciStreamSendmsg':
../linux/af_vsock.c:4079: error: `wait' undeclared (first use in this
function)
../linux/af_vsock.c: In function `VSockVmciStreamRecvmsg':
../linux/af_vsock.c:4428: error: `wait' undeclared (first use in this
function)
make[4]: *** [af_vsock.o] Error 1
make[4]: Leaving directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock/driver-2.4.36'
make[3]: *** [driver] Error 2
make[3]: Leaving directory
`/usr/src/vm-tools-2008.09.03-114782/modules/linux/vsock'
make[2]: *** [vsock] Error 2
make[2]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/vm-tools-2008.09.03-114782'
make: *** [/usr/src/log/vm-tools-2008.09.03-114782] Error 2

Someone have any idea?
(I run compile with some parameters that exclude some (optional ?) librarys)

Sorry for my english :-\

Best regards.
Davide

Hi Guy,

Guy Ellis wrote:
> Totally. Both ADSL2+ cards have their own onboard processor, that
> manages the DSP, and handles SAR.
> This reduces the host load, and the cards will sync up without a
> driver.

Okay, so they can act as a bridge modem then?  Virtually self controlled and 
powered by the PCI bus, but offering WAN IP to IPCOP's red interface?

Are they also Annex M capable?

Kind Regards
AndrewM

Achim Weber wrote:

>> The biggest problem I see is that the amount of data will grow 
>> immensely, 2 hours with virtually no traffic amounts to > 300 KB.
>> So I think we should make this optional, i.e. switch logging on/off on 
>> demand or even log selectively.
> 
> Yes, I was worry about this too :-( 
> 
> For the start I used/log all columns/data which could be interesting. My idea
> is to log all interesting data but only aggregate/show the data per interfaces
> (like in 1.4 ipac-ng). So if someone want more detailed data [aggregation], it
> would be possible easy. But too we can provide detailed data aggregation which
> can be disabled.

I think we can start with 3 GUI options:
accounting disabled,
accounting enabled with data aggregated per interface,
accounting enabled with all the gory details

Create an accounting CGI page either in status or services menu, where 
this can be set and data will be displayed.


> An idea for reducing data is to run the [daily] aggregation every hour. So
> there where not every packet in the database but only the aggregated data
> (only the packets of the last hour are dully detailed).

This could be a GUI option as well, aggregation hourly/daily/weekly.

For all these options we'd probably need a SUID helper.


>> And also do some weekly/monthly volume aggregation, which should not be 
>> a problem with some SQL wizardry.
> 
> I would do a volume aggregation per day. If we log the same data
> (input/output/forward in/forward out) as in 1.4, the daily traffic would only
> need four database entries per interface. This should be not need that much
> amount on the disk/database.

If possible have recent data with more details, i.e. something like last 
week with daily data, last month with weekly data, older data monthly only.

But I think this is something of lesser concern, given the SQL flexibility.


>> PS: we'd also need ulogd rules in the output chain.
> 
> Yes, I forgot that, thanks. I will add this when I move all the rules to the
> right place/another script. 

OK.


>> PPS: is there a specific need for /var/log/ulogd.log? Easier to stick to 
>> messages for logging?
> 
> No, no need for this. I was not sure if there is a problem when writing
> to messages by ulogd, so I did use ulogd.log for now. I will try logging to
> messages.

I do not know if anything valuable will show up, if so we could add an 
accounting section in system log page.


Anyways, good stuff with a lot of potential.
I'll remove vnstat in the next days.


Olaf

-- 

A weizen a day helps keep the doctor away.

Hi Olaf

> I've just played a bit with the recently added ulogd / sqlite combo and 
> I must say that this definitely shows potential :-)

;-)

 
> The biggest problem I see is that the amount of data will grow 
> immensely, 2 hours with virtually no traffic amounts to > 300 KB.
> So I think we should make this optional, i.e. switch logging on/off on 
> demand or even log selectively.

Yes, I was worry about this too :-( 

For the start I used/log all columns/data which could be interesting. My idea
is to log all interesting data but only aggregate/show the data per interfaces
(like in 1.4 ipac-ng). So if someone want more detailed data [aggregation], it
would be possible easy. But too we can provide detailed data aggregation which
can be disabled.

An idea for reducing data is to run the [daily] aggregation every hour. So
there where not every packet in the database but only the aggregated data
(only the packets of the last hour are dully detailed).


> And also do some weekly/monthly volume aggregation, which should not be 
> a problem with some SQL wizardry.

I would do a volume aggregation per day. If we log the same data
(input/output/forward in/forward out) as in 1.4, the daily traffic would only
need four database entries per interface. This should be not need that much
amount on the disk/database.


> There is one great advantage, logging is detailed.

But needs much database/disk space ;-)


> PS: we'd also need ulogd rules in the output chain.

Yes, I forgot that, thanks. I will add this when I move all the rules to the
right place/another script. 


> PPS: is there a specific need for /var/log/ulogd.log? Easier to stick to 
> messages for logging?

No, no need for this. I was not sure if there is a problem when writing
to messages by ulogd, so I did use ulogd.log for now. I will try logging to
messages.

Achim

Hello Achim and all,


I've just played a bit with the recently added ulogd / sqlite combo and 
I must say that this definitely shows potential :-)

The biggest problem I see is that the amount of data will grow 
immensely, 2 hours with virtually no traffic amounts to > 300 KB.
So I think we should make this optional, i.e. switch logging on/off on 
demand or even log selectively.
And also do some weekly/monthly volume aggregation, which should not be 
a problem with some SQL wizardry.

There is one great advantage, logging is detailed.


Olaf


PS: we'd also need ulogd rules in the output chain.
PPS: is there a specific need for /var/log/ulogd.log? Easier to stick to 
messages for logging?

-- 

A weizen a day helps keep the doctor away.

Eric Oberlander wrote:
> On Sat, Oct 18, 2008 at 9:30 AM, SourceForge.net
> <no...@so...>  wrote:
>    
>> Bugs item #2176286, was opened at 2008-10-18 01:30
>> 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=2176286&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.21
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: David W Studeman (Davesworld) (davews)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: Proxy access.log permissions on flash installs
>>
>> Initial Comment:
>> When creating a flash image with the latest mkflash script, /var/log/squid/access.log does not exist upon booting a new flash image and is not created by the touch command in rc.flash.up. It is created when one activates the proxy log in the web gui and the resultant mode is 640 not 644. Since the file is one of the files that get compressed with rc.flash.down and if it exists there already, it is left intact with the same mode it was saved in. This patch in the mkflash script completely solves the problem and upon first boot, the access.log file exists properly as mode 644 squid:squid so if the proxy is activated and log enabled, it is readily readable by the web gui with no manual intervention.
>>
>> Also note as per Eric Oberlander, prior to this solution, by deleting the /var/log/squid directory and rebooting, the proper file and mode are there, in the absense of this directory, rc.flash.up will touch properly since sysinit runs with a umask of 022. The changes to mkflash in the below preclude the need to do any of this.
>>
>> Dave Studeman
>>      
>
> Hi David
>
> To clarify something that's bugging me, I think you said in the
> previous thread that the 1.9,3 mkflash script works OK, but the 1,4,X
> version does not.
>
> I don't see a huge difference between the two scripts, so why do we
> need to patch one and not the other?
>
> Eric
>
>    
  I should have been more clear about why 1.9.3 DID work. 1.9.3 tests I 
installed as flash installs from the install cd and never used the 
mkflash script since 1.9.1 I think and even then I never checked proxy 
logs. So your assertion is correct as both mkflash scripts are very similar.

Dave

On Sat, Oct 18, 2008 at 9:30 AM, SourceForge.net
<no...@so...> wrote:
> Bugs item #2176286, was opened at 2008-10-18 01:30
> 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=2176286&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.21
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: David W Studeman (Davesworld) (davews)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Proxy access.log permissions on flash installs
>
> Initial Comment:
> When creating a flash image with the latest mkflash script, /var/log/squid/access.log does not exist upon booting a new flash image and is not created by the touch command in rc.flash.up. It is created when one activates the proxy log in the web gui and the resultant mode is 640 not 644. Since the file is one of the files that get compressed with rc.flash.down and if it exists there already, it is left intact with the same mode it was saved in. This patch in the mkflash script completely solves the problem and upon first boot, the access.log file exists properly as mode 644 squid:squid so if the proxy is activated and log enabled, it is readily readable by the web gui with no manual intervention.
>
> Also note as per Eric Oberlander, prior to this solution, by deleting the /var/log/squid directory and rebooting, the proper file and mode are there, in the absense of this directory, rc.flash.up will touch properly since sysinit runs with a umask of 022. The changes to mkflash in the below preclude the need to do any of this.
>
> Dave Studeman

Hi David

To clarify something that's bugging me, I think you said in the
previous thread that the 1.9,3 mkflash script works OK, but the 1,4,X
version does not.

I don't see a huge difference between the two scripts, so why do we
need to patch one and not the other?

Eric

Hi

The IPCop Language Database for translations at http://www.ipcop.org/langs/
is back online, after some issues, caused by the recent move and
upgrades on Sourceforge, were resolved. Thanks to Mark Wormgoor.

Hi Guy,

first off, thanks for your explanations and comments, much appreciated.


> (i) Pulsar, ADSL1, ATM Class
> Already integrated and does work with 2.4 and 2.6 kernels.
> If there are any specific problems with 2.6.27 just let me know and we'll 
> fix them.

Pulsar (v4.0.24) compiles up to the latest and greatest 2.6.27.2

There are 2 warnings which I do not think are a problem yet, but might 
be one day:
make[1]: Entering directory `/usr/src/pulsar-4.0.24'
make -C /lib/modules/2.6.27/build SUBDIRS=/usr/src/pulsar-4.0.24 modules
make[2]: Entering directory `/usr/src/linux-2.6.27'
   CC [M]  /usr/src/pulsar-4.0.24/pulsar.o
/usr/src/pulsar-4.0.24/pulsar.c: In function 'pulsar_init':
/usr/src/pulsar-4.0.24/pulsar.c:1233: warning: 'pci_find_device' is 
deprecated (declared at include/linux/pci.h:537)
/usr/src/pulsar-4.0.24/pulsar.c: In function 'pulsar_exit':
/usr/src/pulsar-4.0.24/pulsar.c:1257: warning: 'pci_find_device' is 
deprecated (declared at include/linux/pci.h:537)


I can file a feature request / bug report on SF if you wish.


> (iii) Solos-PCI, 2/4 Port ADSL2+, ATM class
> We need to give this a bit more thought about how this could be integrated,
> i.e how does the 2nd port work. Is it just for ML-PPP?
> It could also be used for load sharing and/or redundancy?

I guess that would depend on what level of complexity, extra SW, etc. 
needs to be added for those features.


> At this stage we only plan to support 2.6 kernels with this driver.

Fine with me.


Olaf

-- 

A weizen a day helps keep the doctor away.

Hi Olaf,

There are three ADSL cards we manufacture...

(i) Pulsar, ADSL1, ATM Class
Already integrated and does work with 2.4 and 2.6 kernels.
If there are any specific problems with 2.6.27 just let me know and we'll 
fix them.
This driver also supports the Sangoma S518, which is an alternative to wanpipe.

http://sourceforge.net/project/showfiles.php?group_id=117362&package_id=127793

(ii) Viking, ADSL2+, Ethernet Class
Gilles is looking at integrating this card.
It uses a RTL8139C+ chip so no special drivers are required.
It should work fine 2.6.27

(iii) Solos-PCI, 2/4 Port ADSL2+, ATM class
We need to give this a bit more thought about how this could be integrated,
i.e how does the 2nd port work. Is it just for ML-PPP?
It could also be used for load sharing and/or redundancy?
Gilles only has one ADSL line so that is also a problem.

At this stage we only plan to support 2.6 kernels with this driver.
If there are any specific issues with 2.6.27 we can fix them.

http://sourceforge.net/project/showfiles.php?group_id=117362&package_id=295504

I hope this helps.

Kind regards,

  - Guy.

At 05:16 PM 18/10/2008 +0200, Olaf Westrik wrote:
>Guy Ellis wrote:
>
>>We've developed two new ADSL2+ modems since I was here last, and I was 
>>wondering if there might be any interest in integrating them.
>
>Which kernel versions are supported, or will be, by the drivers?
>
>I am asking because I am considering moving to 2.6.27 for the next major 
>version of IPCop (2.0) and there is already a long list of drivers [1] 
>that we currently have around in 1.4 that stop compiling on recent kernels.
>
>
>Olaf
>
>
>[1] 3cp4218, amedyn2, CnxADSL, eciadsl, wanpipe, all fcdsl variants
>
>--
>
>A weizen a day helps keep the doctor away.


------------------------------------------------------------------
Guy Ellis
gu...@tr...
http://www.traverse.com.au
Tel: +613 9486 7775
Fax: +613 9482 7754
Mobile: 0419 398 234
Skype: guy.ellis1
------------------------------------------------------------------

Guy Ellis wrote:

> We've developed two new ADSL2+ modems since I was here last, and I was 
> wondering if there might be any interest in integrating them.

Which kernel versions are supported, or will be, by the drivers?

I am asking because I am considering moving to 2.6.27 for the next major 
version of IPCop (2.0) and there is already a long list of drivers [1] 
that we currently have around in 1.4 that stop compiling on recent kernels.


Olaf


[1] 3cp4218, amedyn2, CnxADSL, eciadsl, wanpipe, all fcdsl variants

-- 

A weizen a day helps keep the doctor away.

Bugs item #2176286, was opened at 2008-10-18 01:30
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=2176286&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.21
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David W Studeman (Davesworld) (davews)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy access.log permissions on flash installs

Initial Comment:
When creating a flash image with the latest mkflash script, /var/log/squid/access.log does not exist upon booting a new flash image and is not created by the touch command in rc.flash.up. It is created when one activates the proxy log in the web gui and the resultant mode is 640 not 644. Since the file is one of the files that get compressed with rc.flash.down and if it exists there already, it is left intact with the same mode it was saved in. This patch in the mkflash script completely solves the problem and upon first boot, the access.log file exists properly as mode 644 squid:squid so if the proxy is activated and log enabled, it is readily readable by the web gui with no manual intervention. 

Also note as per Eric Oberlander, prior to this solution, by deleting the /var/log/squid directory and rebooting, the proper file and mode are there, in the absense of this directory, rc.flash.up will touch properly since sysinit runs with a umask of 022. The changes to mkflash in the below preclude the need to do any of this.

Dave Studeman



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

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

Tapani Tarvainen wrote:

>>> But, how about multiple Orange interfaces?
> 
>> We are not opposed to good code changes in form of patches targeted for 2.0.
>> This is just than olaf and me will not start those changes now.
> 
> That's fine - indeed I was mainly sounding out if others are
> interested, 'cause I was thinking I might have a go at it myself 
> (not this month though, but I hope I won't be quite this busy forever).

Multiple oranges (and greens and blues) are planned as far as I'm 
concerned and will come (one day). Not in 2.0 but some later version.


Olaf

-- 

A weizen a day helps keep the doctor away.

David Raine wrote:

>>> b) kernel/tc support for ATM link layer

[snip]

> I now believe that the kernel patches I need made it into 2.6.25.

Looks like it. Did not completely verify though.
According this there are still bits and pieces missing in .24 
http://www.adsl-optimizer.dk/ADSL-optimizer/patches/mainline_2.6.24/

They may have made it into .25 but a quick search did not turn up any 
information.


Olaf

-- 

A weizen a day helps keep the doctor away.

Glen Cunningham wrote:

>      Small problem doing a build from the latest svn.  prefetch fails 
> trying to get coreutils-6.10-i18n-1.patch from
> <http://www.linuxfromscratch.org/patches/lfs/development/>
> 
>      No big deal, the file is actually at ...
> <http://www.linuxfromscratch.org/patches/downloads/coreutils/coreutils-6.10-i18n-1.patch>
>     A manual wget of the patch and the build completes fine.
> 
>   However, it probably is not simply a matter of changing the value of 
> URL_LFS_DEV  in ./trunk/lfs/Config as I suspect that this is used in 
> other places

I think we'll take $(URL_LFS)/$(PKG_NAME)/$(PATCH1) as download location ;-)


Thanks

Olaf

-- 

A weizen a day helps keep the doctor away.