ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "IPCop devel" <ipc...@li...>
Sent: Tuesday, September 28, 2010 9:13 PM
Subject: [IPCop-devel] 'freeze' for 1.9.16


> If there are things left in your local trees, commit till Friday, 1st
> October 22:00 UTC.
> If nothing comes up during final tests, expect to see 1.9.16 released
> Saturday or Sunday.
>
> After that we can upgrade gcc, and prepare for the 1.9.17 upgrade.
>
>
> Olaf
>
I have nothing ready yet.

I had a look at isomd5sum and have compiled the package.
This would allow to check iso md5 at boot. The checksum is not written on
the filesystem but on iso9660 data structure. I need to plug that to the
installer.

I have some clues how to reduce gcc test errors (same for gcc-4.4.4 and
4.4.5)
We actually have
FAIL: g++.dg/parse/error14.C at end of input (test for errors, line 22)
FAIL: g++.dg/parse/error14.C (test for excess errors)
FAIL: g++.dg/parse/error5.C  (test for errors, line 4)
FAIL: g++.dg/parse/error5.C (test for excess errors)
FAIL: g++.dg/gomp/critical-2.C  (test for errors, line 9)
FAIL: g++.dg/gomp/critical-2.C (test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O0  (test for excess
errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O1  (test for excess
errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O2  (test for excess
errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O3 -fomit-frame-pointer
(test for excess errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -O3 -g  (test for excess
errors)
FAIL: gcc.c-torture/compile/limits-exprparen.c  -Os  (test for excess
errors)
FAIL: gcc.dg/gomp/appendix-a/a.20.1.c  (test for errors, line 10)
FAIL: gcc.dg/gomp/appendix-a/a.20.1.c  (test for errors, line 14)
FAIL: gcc.dg/gomp/appendix-a/a.20.1.c (test for excess errors)
FAIL: gcc.dg/gomp/critical-2.c  (test for errors, line 9)
FAIL: gcc.dg/gomp/critical-2.c (test for excess errors)
FAIL: gcc.dg/gomp/for-3.c  (test for errors, line 9)
FAIL: gcc.dg/gomp/for-3.c (test for excess errors)
FAIL: libmudflap.c++/pass41-frag.cxx execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
FAIL: abi_check


Setting ulimit -s from 8192 to 16384 on my user profile, the 6
gcc.c-torture errors diseappear.

Using --with-include-gettext (and not yet sure without --disable-nls), the 6
g++.dg and 6 gcc.dg errors disappear.

So only libmudflap and abi_check errors may remain.
I will look at abi_check test log to understand what happen there.
Good to know where the errors come from
Another point is should we change our settings for that?

I should look too at autoconf-2.68 and m4-1.4.15 but I should say I am
waiting for LFS changes commited before.

Gilles

If there are things left in your local trees, commit till Friday, 1st 
October 22:00 UTC.
If nothing comes up during final tests, expect to see 1.9.16 released 
Saturday or Sunday.

After that we can upgrade gcc, and prepare for the 1.9.17 upgrade.


Olaf

On 2010-09-27 22:27, Gilles Espinasse wrote:

>> Probably best to do an update with our current changes, including the
>> just released Openswan 2.6.29. Followed by an update with the files
>> changed by gcc 4.4.5
>
> Fully agree
> Probably we should add openvpn-2.1.3 to the first update (and kernel
> 2.6.32.23)

All done and briefly tested.
At the moment I have no more important modifications left. So if there 
are no objections/problems I will release 1.9.16 coming weekend.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: <ipc...@li...>
Sent: Monday, September 27, 2010 10:23 PM
Subject: Re: [IPCop-devel] [Ipcop-svn] new lsof timestamp


>
> > We have more important question with new gcc-4.4.5
> > In gcc-4.4.5, the component that have been find to misscompile the
> > linux-2.6.35 kernel has been disabled as being old (1993) and not really
> > needed.
> > For more details, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
> >
> > I used files_check with svn compiled against gcc-4.4.5-RC-20100924
> >
> > We will have a lot of different files (726). I haven't checked the log
yet
> > to see if there is a visible difference in the log. Probably many of
them
> > similary include the compiler name. It may be hard to find the few files
> > that may have been really miscompiled in 4.4.4 and fixed in 4.4.5, so
the
> > simpliest way is to include every changed files.
>
> Sounds like a big update.
> Probably best to do an update with our current changes, including the
> just released Openswan 2.6.29. Followed by an update with the files
> changed by gcc 4.4.5
>
>
> Olaf

Fully agree
Probably we should add openvpn-2.1.3 to the first update (and kernel
2.6.32.23)
Just compiled openvpn, not run
svn diff lfs/openvpn
Index: lfs/openvpn
===================================================================
--- lfs/openvpn (revision 4976)
+++ lfs/openvpn (working copy)
@@ -33,7 +33,7 @@
 include Config

 PKG_NAME   = openvpn
-VER        = 2.1.1
+VER        = 2.1.3
 HOST_ARCH  = all
 OTHER_SRC  = yes

@@ -45,7 +45,7 @@

 # Used to include same timestamp for all
 # This is the release date
-DATESTAMP = "Dec 11 2009"
+DATESTAMP = "Sept 09 2010"


############################################################################
###
 # Top-level Rules
@@ -55,7 +55,7 @@

 $(DL_FILE) = $(DL_FROM)/$(DL_FILE)

-$(DL_FILE)_MD5 = b273ed2b5ec8616fb9834cde8634bce7
+$(DL_FILE)_MD5 = 7486d3e270ba4b033e311d3e022a0ad7

 install : $(TARGET)

Gilles

On 2010-09-27 08:33, Gilles Espinasse wrote:

>>> Instead, should we not add lsof in files-with-different-md5 with the
>>> multiples reasons?
>>
>> I am not sure.
>> Alternatively we can strip out the compiler flags from lsof -v. That's
>> not really interesting in our case.
>>
> Require some work and more attention on upgrade with little gain.
>
>> What do you think?
>>
> I would not care of lsof binary detail change, just include the new one in
> update.

OK. Reverting lfs/lsof as we speak.


> We have more important question with new gcc-4.4.5
> In gcc-4.4.5, the component that have been find to misscompile the
> linux-2.6.35 kernel has been disabled as being old (1993) and not really
> needed.
> For more details, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
>
> I used files_check with svn compiled against gcc-4.4.5-RC-20100924
>
> We will have a lot of different files (726). I haven't checked the log yet
> to see if there is a visible difference in the log. Probably many of them
> similary include the compiler name. It may be hard to find the few files
> that may have been really miscompiled in 4.4.4 and fixed in 4.4.5, so the
> simpliest way is to include every changed files.

Sounds like a big update.
Probably best to do an update with our current changes, including the 
just released Openswan 2.6.29. Followed by an update with the files 
changed by gcc 4.4.5


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: <ipc...@li...>
Sent: Sunday, September 26, 2010 10:32 PM
Subject: Re: [IPCop-devel] [Ipcop-svn] new lsof timestamp


> On 2010-09-26 16:59, Gilles Espinasse wrote:
>
> >>   # Used to include same timestamp for all
> >>   # This is the release date
> >> -DATESTAMP = "2010-07-29 12:09:00"
> >> +DATESTAMP = "2010-09-21 20:08:35"
> >>
> >   I don't think that's the better answer.
> > If we upgrade to gcc-4.4.5, should we update the timestamp again?
> >
> > Instead, should we not add lsof in files-with-different-md5 with the
> > multiples reasons?
>
> I am not sure.
> Alternatively we can strip out the compiler flags from lsof -v. That's
> not really interesting in our case.
>
Require some work and more attention on upgrade with little gain.

> What do you think?
>
I would not care of lsof binary detail change, just include the new one in
update.

We have more important question with new gcc-4.4.5
In gcc-4.4.5, the component that have been find to misscompile the
linux-2.6.35 kernel has been disabled as being old (1993) and not really
needed.
For more details, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312

I used files_check with svn compiled against gcc-4.4.5-RC-20100924

We will have a lot of different files (726). I haven't checked the log yet
to see if there is a visible difference in the log. Probably many of them
similary include the compiler name. It may be hard to find the few files
that may have been really miscompiled in 4.4.4 and fixed in 4.4.5, so the
simpliest way is to include every changed files.

Gilles

On 2010-09-26 16:59, Gilles Espinasse wrote:

>>   # Used to include same timestamp for all
>>   # This is the release date
>> -DATESTAMP = "2010-07-29 12:09:00"
>> +DATESTAMP = "2010-09-21 20:08:35"
>>
>   I don't think that's the better answer.
> If we upgrade to gcc-4.4.5, should we update the timestamp again?
>
> Instead, should we not add lsof in files-with-different-md5 with the
> multiples reasons?

I am not sure.
Alternatively we can strip out the compiler flags from lsof -v. That's 
not really interesting in our case.

What do you think?


Olaf

----- Original Message ----- 
From: <ow...@us...>
To: <ipc...@li...>
Sent: Sunday, September 26, 2010 4:14 PM
Subject: [Ipcop-svn] SF.net SVN: ipcop:[4973] ipcop/trunk/lfs/lsof


> Revision: 4973
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=4973&view=rev
> Author:   owes
> Date:     2010-09-26 14:14:32 +0000 (Sun, 26 Sep 2010)
>
> Log Message:
> -----------
> lsof -v outputs compiler flags, including kernelversion. Include lsof in
update after kernelupgrade using new datestamp.
>
> Modified Paths:
> --------------
>     ipcop/trunk/lfs/lsof
>
> Modified: ipcop/trunk/lfs/lsof
> ===================================================================
> --- ipcop/trunk/lfs/lsof 2010-09-26 13:10:15 UTC (rev 4972)
> +++ ipcop/trunk/lfs/lsof 2010-09-26 14:14:32 UTC (rev 4973)
> @@ -45,7 +45,7 @@
>
>  # Used to include same timestamp for all
>  # This is the release date
> -DATESTAMP = "2010-07-29 12:09:00"
> +DATESTAMP = "2010-09-21 20:08:35"
>
 I don't think that's the better answer.
If we upgrade to gcc-4.4.5, should we update the timestamp again?

Instead, should we not add lsof in files-with-different-md5 with the
multiples reasons?

By the way, I have compiled gcc-4.4.5-RC-20100924.
I still need to check which files have changed.
gcc-4.4.5 should be released at the end of next week.

Gilles

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Wednesday, September 08, 2010 4:40 PM
Subject: Re: [IPCop-devel] /tmp not writable by the user


> On 2010-09-07 13:43, Gilles Espinasse wrote:
>
> >>>> How about we make that ${BASEDIR}/tmp_${MACHINE}?
> >>>> If it exists on build start we can clean it and do not have to worry
> >>>> about interfering with other things.
> >>>>
> >>> Much cleaner than my cache/tmp. I will do that
> >>
> >> Another option would be to use ${BASEDIR}/build_${MACHINE}/tmp
> >>
> > I was thinking it was better : cleaning will be already done.
> > But that force us to remade a new toolchain package and shift tmp
directory
> > creation from stage2 to make.sh
>
> I have no problem with a new toolchain.
> If it needs to be changed, we change it.
>
>
> Olaf

gcc-4.4.5 should not be away now
http://gcc.gnu.org/ml/gcc/2010-09/msg00146.html

I will try with gcc-4.4-20100914 or wait rc release.
That would be a good reason to update the toolchain package.

Gilles

On 09/17/2010 11:09 PM, Olaf Westrik wrote:
> On 2010-09-14 22:18, David W Studeman wrote:
> 
>>> Olaf, you got those Raqs out of mothball yet?
> 
> I'm afraid not.

 I didn't even know you had moved until you mentioned it on my forum
seeing as the commits have been coming at a pretty good pace for some
time now.

> 
>> I just compiled a build with fairly heavy kernel debugging built in. I
>> get this when it crashes at init:
>>
>> INIT: version 2.88 booting
>>
>> Kernel panic - not syncing: Attempted to kill init!
>> Pid: 1, comm: init Not tainted 2.6.32-1-cobalt #2
>> Call Trace:
>>   [<c028cfd8>] ? printk+0xf/0x17
>>   [<c028cf2d>] panic+0x39/0xd5
>>   [<c0119ce7>] do_exit+0x54/0x519
>>   [<c011a20d>] do_group_exit+0x61/0x84
>>   [<c0121368>] get_signal_to_deliver+0x2e9/0x300
>>   [<c01036d0>] ? do_invalid_op+0x0/0x7b
>>   [<c0101d2a>] do_signal+0x58/0x6dc
>>   [<c0121aef>] ? force_sig_info+0x9d/0xa7
>>   [<c0103444>] ? do_trap+0x54/0xa1
>>   [<c012a73f>] ? cpu_clock+0x2d/0x4e
>>   [<c012a73f>] ? cpu_clock+0x2d/0x4e
>>   [<c013067b>] ? lock_release_holdtime+0x2d/0xc6
>>   [<c010298f>] ? restore_all_notrace+0x0/0x18
>>   [<c010bf38>] ? do_page_fault+0x0/0x1f7
>>   [<c0131732>] ? trace_hardirqs_on_caller+0x105/0x12c
>>   [<c01036d0>] ? do_invalid_op+0x0/0x7b
>>   [<c01023be>] do_notify_resume+0x10/0x2e
>>   [<c0102a42>] work_notifysig+0x13/0x21
>>
>> Is this usable info?
>>
> 
> To me that looks like an invalid opcode, probably due to a build setting 
> that is not working correctly for AMD K6.
> 
> 
> Olaf
> 

Ah, I have a better picture now. This would explain why the same build
runs fine on a P-III Coppermine Cobalt.

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

On 2010-09-14 22:18, David W Studeman wrote:

>> Olaf, you got those Raqs out of mothball yet?

I'm afraid not.


> I just compiled a build with fairly heavy kernel debugging built in. I
> get this when it crashes at init:
>
> INIT: version 2.88 booting
>
> Kernel panic - not syncing: Attempted to kill init!
> Pid: 1, comm: init Not tainted 2.6.32-1-cobalt #2
> Call Trace:
>   [<c028cfd8>] ? printk+0xf/0x17
>   [<c028cf2d>] panic+0x39/0xd5
>   [<c0119ce7>] do_exit+0x54/0x519
>   [<c011a20d>] do_group_exit+0x61/0x84
>   [<c0121368>] get_signal_to_deliver+0x2e9/0x300
>   [<c01036d0>] ? do_invalid_op+0x0/0x7b
>   [<c0101d2a>] do_signal+0x58/0x6dc
>   [<c0121aef>] ? force_sig_info+0x9d/0xa7
>   [<c0103444>] ? do_trap+0x54/0xa1
>   [<c012a73f>] ? cpu_clock+0x2d/0x4e
>   [<c012a73f>] ? cpu_clock+0x2d/0x4e
>   [<c013067b>] ? lock_release_holdtime+0x2d/0xc6
>   [<c010298f>] ? restore_all_notrace+0x0/0x18
>   [<c010bf38>] ? do_page_fault+0x0/0x1f7
>   [<c0131732>] ? trace_hardirqs_on_caller+0x105/0x12c
>   [<c01036d0>] ? do_invalid_op+0x0/0x7b
>   [<c01023be>] do_notify_resume+0x10/0x2e
>   [<c0102a42>] work_notifysig+0x13/0x21
>
> Is this usable info?
>

To me that looks like an invalid opcode, probably due to a build setting 
that is not working correctly for AMD K6.


Olaf

On 09/14/2010 12:26 AM, David W Studeman wrote:
>  I've been searching quite extensively on how to get output for
> debugging purposes. In this case, starting at rev 4719 I get this error
> ONLY while trying to boot and run this and any newer revision including
> r4956 on 3000 series (AMD K6-2 and 3, Ali chipset). The 550 Runs ok.
> Snippet:
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
> Freeing unused kernel memory: 156k freed
> INIT: version 2.88 booting
> Kernel panic - not syncing: Attempted to kill init!
> 
> Is there any proper way to have it debug init and have it output to
> ttyS0? Since root does not get mounted read/write until after sysinit
> starts, there is no other way to get debug output that I can see without
> outputting it to the only thing available and that is the serial
> cosnole. Is it possible to add a debug to inittab? Or should it be in
> sysinit? The info on inittab is rather sparse that I could find.
> 
> To refesh. By looking at rev 4719 as being a glibc upgrade and when this
> problem started to occur, the first thing I tried was making post 4718
> builds with the previous version of glibc, it still behaved the same
> way, same with reverting to gcc 4.4.3. I used the old lfs scripts on
> these as I mentioned in another thread because I did not want to alter
> these two in any way from where they were at rev 4718.
> 
> Olaf, you got those Raqs out of mothball yet?
> 

I just compiled a build with fairly heavy kernel debugging built in. I
get this when it crashes at init:

INIT: version 2.88 booting

Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 2.6.32-1-cobalt #2
Call Trace:
 [<c028cfd8>] ? printk+0xf/0x17
 [<c028cf2d>] panic+0x39/0xd5
 [<c0119ce7>] do_exit+0x54/0x519
 [<c011a20d>] do_group_exit+0x61/0x84
 [<c0121368>] get_signal_to_deliver+0x2e9/0x300
 [<c01036d0>] ? do_invalid_op+0x0/0x7b
 [<c0101d2a>] do_signal+0x58/0x6dc
 [<c0121aef>] ? force_sig_info+0x9d/0xa7
 [<c0103444>] ? do_trap+0x54/0xa1
 [<c012a73f>] ? cpu_clock+0x2d/0x4e
 [<c012a73f>] ? cpu_clock+0x2d/0x4e
 [<c013067b>] ? lock_release_holdtime+0x2d/0xc6
 [<c010298f>] ? restore_all_notrace+0x0/0x18
 [<c010bf38>] ? do_page_fault+0x0/0x1f7
 [<c0131732>] ? trace_hardirqs_on_caller+0x105/0x12c
 [<c01036d0>] ? do_invalid_op+0x0/0x7b
 [<c01023be>] do_notify_resume+0x10/0x2e
 [<c0102a42>] work_notifysig+0x13/0x21

Is this usable info?

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

 I've been searching quite extensively on how to get output for
debugging purposes. In this case, starting at rev 4719 I get this error
ONLY while trying to boot and run this and any newer revision including
r4956 on 3000 series (AMD K6-2 and 3, Ali chipset). The 550 Runs ok.
Snippet:
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
Freeing unused kernel memory: 156k freed
INIT: version 2.88 booting
Kernel panic - not syncing: Attempted to kill init!

Is there any proper way to have it debug init and have it output to
ttyS0? Since root does not get mounted read/write until after sysinit
starts, there is no other way to get debug output that I can see without
outputting it to the only thing available and that is the serial
cosnole. Is it possible to add a debug to inittab? Or should it be in
sysinit? The info on inittab is rather sparse that I could find.

To refesh. By looking at rev 4719 as being a glibc upgrade and when this
problem started to occur, the first thing I tried was making post 4718
builds with the previous version of glibc, it still behaved the same
way, same with reverting to gcc 4.4.3. I used the old lfs scripts on
these as I mentioned in another thread because I did not want to alter
these two in any way from where they were at rev 4718.

Olaf, you got those Raqs out of mothball yet?

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

On 11 September 2010 17:23, John Edwards <jo...@co...> wrote:
> Hi
>
> I met an odd problem yesterday on IPcop 1.4.21 where changing the
> DHCP settings in the setup program to add a new DNS server wrote a
> dhcpd.conf file, but without the fixed leases that had been defined
> in the CGI page. Going to the CGI page and clicking "Save" wrote a
> dhcpd.conf with all the fixed leases.
>
> Could someone else try this and repeat this on another IPCop system?
>
>
> It looks like the CGI page and the setup program are using different
> functions to build the dhcpd.conf file. If so then I think the
> simplest solution would be move this function to a separate script
> which is run by both programs.
>
> If we only doing security fixes for the 1.4 series and I'm the first
> person to notice this, then an alternative could be to document this
> as a known problem in the  and tell people to only use the CGI page
> for DHCP with fixed leases.
>
>
> I've had a quick look at the source for 1.9.x:
>    http://sourceforge.net/apps/trac/ipcop/browser/ipcop/trunk/html/cgi-bin/dhcp.cgi
>
> There are references in comments of that file to dhcpd.conf but
> the main writeconf functions only writes to dnsmasq's DHCP config
> file. I am guessing that the comments are out of sync with the code.

Hi John

I think it only pertains to the v1.4.x code, as v1.9.x uses dnsmasq
for DHCP, and if you look in the dnsmasq.conf file, you will see that
fixed leases are in a separate, linked file, which shouldn't be
affected by changes via the Installer.

(I haven't tested this though).

Eric

On 2010-09-11 18:23, John Edwards wrote:

> I met an odd problem yesterday on IPcop 1.4.21 where changing the
> DHCP settings in the setup program to add a new DNS server wrote a
> dhcpd.conf file, but without the fixed leases that had been defined
> in the CGI page. Going to the CGI page and clicking "Save" wrote a
> dhcpd.conf with all the fixed leases.
>
> Could someone else try this and repeat this on another IPCop system?

There is no mystery there.
install/setup only writes a few basic settings to dhcpd.conf
No where near as complete as the GUI.


> It looks like the CGI page and the setup program are using different
> functions to build the dhcpd.conf file. If so then I think the
> simplest solution would be move this function to a separate script
> which is run by both programs.

IMHO a much easier solution is to no longer have any DHCP tinkering by 
setup at all. Only install time to get some basics up and running and 
use the GUI afterwards.


> If we only doing security fixes for the 1.4 series and I'm the first
> person to notice this, then an alternative could be to document this
> as a known problem in the  and tell people to only use the CGI page
> for DHCP with fixed leases.

In the ...  documentation? faq?  Anybody reading those?

And yes, after who knows how many years, you are the first to notice.


> I've had a quick look at the source for 1.9.x:
>      http://sourceforge.net/apps/trac/ipcop/browser/ipcop/trunk/html/cgi-bin/dhcp.cgi
>
> There are references in comments of that file to dhcpd.conf but
> the main writeconf functions only writes to dnsmasq's DHCP config
> file. I am guessing that the comments are out of sync with the code.

dhcpd.conf is gone. The only remaining memory is not 100% correct comment.


Olaf

Hi

I met an odd problem yesterday on IPcop 1.4.21 where changing the
DHCP settings in the setup program to add a new DNS server wrote a
dhcpd.conf file, but without the fixed leases that had been defined
in the CGI page. Going to the CGI page and clicking "Save" wrote a
dhcpd.conf with all the fixed leases.

Could someone else try this and repeat this on another IPCop system?


It looks like the CGI page and the setup program are using different
functions to build the dhcpd.conf file. If so then I think the
simplest solution would be move this function to a separate script
which is run by both programs.

If we only doing security fixes for the 1.4 series and I'm the first
person to notice this, then an alternative could be to document this
as a known problem in the  and tell people to only use the CGI page
for DHCP with fixed leases.


I've had a quick look at the source for 1.9.x:
    http://sourceforge.net/apps/trac/ipcop/browser/ipcop/trunk/html/cgi-bin/dhcp.cgi

There are references in comments of that file to dhcpd.conf but
the main writeconf functions only writes to dnsmasq's DHCP config
file. I am guessing that the comments are out of sync with the code.


-- 
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
#---------------------------------------------------------#

On 2010-09-10 23:03, David W Studeman wrote:

> Ah, I see. Well then, there are now two choices even though one (1.9.x)
> is not production ready. Do you find that the 2.6 kernel supports 802.11
> considerably better?

It does (at least the more recent ones), but there is still room for 
improvement.


Olaf

On 09/09/2010 06:11 AM, Tom Gamble wrote:
> 
> On Thu, 2010-09-09 at 00:46 -0700, David W Studeman wrote:
>> On 9/9/2010 12:17 AM, Tom Gamble wrote:
>>>
>>> On Wed, 2010-09-08 at 13:39 -0700, Necip Celepci wrote:
>>>> hi all,
>>>> i have alix board. i installed ipcop 1.4.21to cf card every think is
>>>> ok. i couldn't install atheros mini pci wifi card for a blue
>>>> interface.
>>>> can you help me? thanks.
>>>>
>>>
>>>
>>> I think you need to use the 1.9.15 but that is not a production/stable
>>> release.  But that said, I have an Alix card with an Atheros mini pci
>>> and it has been as solid as a rock for a number of months now.
>>>
>>> Tom.
>>>
>>
>> Using wireless how? Access point? What? What Necip needs is here 
>> http://www.ban-solms.de/t/IPCop-wlanap.html
>>
> 
> I use wireless as Access point via:-
> http://www.ban-solms.de/t/IPCop-wlanap.html
> 
> 
> Tom.

Ah, I see. Well then, there are now two choices even though one (1.9.x)
is not production ready. Do you find that the 2.6 kernel supports 802.11
considerably better? I had heard it does. Not related but wireless
nonetheless, it sure does with 3G.


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

On Thu, 2010-09-09 at 00:46 -0700, David W Studeman wrote:
> On 9/9/2010 12:17 AM, Tom Gamble wrote:
> >
> > On Wed, 2010-09-08 at 13:39 -0700, Necip Celepci wrote:
> >> hi all,
> >> i have alix board. i installed ipcop 1.4.21to cf card every think is
> >> ok. i couldn't install atheros mini pci wifi card for a blue
> >> interface.
> >> can you help me? thanks.
> >>
> >
> >
> > I think you need to use the 1.9.15 but that is not a production/stable
> > release.  But that said, I have an Alix card with an Atheros mini pci
> > and it has been as solid as a rock for a number of months now.
> >
> > Tom.
> >
> 
> Using wireless how? Access point? What? What Necip needs is here 
> http://www.ban-solms.de/t/IPCop-wlanap.html
> 

I use wireless as Access point via:-
http://www.ban-solms.de/t/IPCop-wlanap.html


Tom.

On 9/9/2010 12:17 AM, Tom Gamble wrote:
>
> On Wed, 2010-09-08 at 13:39 -0700, Necip Celepci wrote:
>> hi all,
>> i have alix board. i installed ipcop 1.4.21to cf card every think is
>> ok. i couldn't install atheros mini pci wifi card for a blue
>> interface.
>> can you help me? thanks.
>>
>
>
> I think you need to use the 1.9.15 but that is not a production/stable
> release.  But that said, I have an Alix card with an Atheros mini pci
> and it has been as solid as a rock for a number of months now.
>
> Tom.
>

Using wireless how? Access point? What? What Necip needs is here 
http://www.ban-solms.de/t/IPCop-wlanap.html

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

On 9/8/2010 1:39 PM, Necip Celepci wrote:
> hi all,
> i have alix board. i installed ipcop 1.4.21to cf card every think is ok.
> i couldn't install atheros mini pci wifi card for a blue interface.
> can you help me? thanks.
>

First of all, the atheros driver is available as part of the access 
point addon for 1.4.21 http://www.ban-solms.de/t/IPCop-wlanap.html.

Second point is that you give no clue as to what you will use wireless 
for? Red? Or as an access point?


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

On Wed, 2010-09-08 at 13:39 -0700, Necip Celepci wrote:
> hi all,
> i have alix board. i installed ipcop 1.4.21to cf card every think is
> ok. i couldn't install atheros mini pci wifi card for a blue
> interface. 
> can you help me? thanks.
> 


I think you need to use the 1.9.15 but that is not a production/stable
release.  But that said, I have an Alix card with an Atheros mini pci
and it has been as solid as a rock for a number of months now.

Tom.

hi all,
i have alix board. i installed ipcop 1.4.21to cf card every think is ok. i couldn't install atheros mini pci wifi card for a blue interface. 
can you help me? thanks.



      

Bugs item #3062133, was opened at 2010-09-08 15:24
Message generated for change (Tracker Item Submitted) made by tweekerdood
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3062133&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: Build
Group: V2 beta
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: TweekerDood (tweekerdood)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.9.15

Initial Comment:
On ESXi 3.5 the following doesn't work:

LSI Logic SCSI adapter
Client Passthrough CD (connect to ISO) - No CD-Rom Found 
Datastore based CD-image (connected to ISO) - No CD-Rom Found 



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

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

On 2010-09-07 13:43, Gilles Espinasse wrote:

>>>> How about we make that ${BASEDIR}/tmp_${MACHINE}?
>>>> If it exists on build start we can clean it and do not have to worry
>>>> about interfering with other things.
>>>>
>>> Much cleaner than my cache/tmp. I will do that
>>
>> Another option would be to use ${BASEDIR}/build_${MACHINE}/tmp
>>
> I was thinking it was better : cleaning will be already done.
> But that force us to remade a new toolchain package and shift tmp directory
> creation from stage2 to make.sh

I have no problem with a new toolchain.
If it needs to be changed, we change it.


Olaf