ipcop-devel Mailing List for IPCop Firewall

Hi

I'm actually getting this all the time on the Blue network. I think it is 
because my Buffalo wifi access point insists on NATing ip addresses and thus 
connections are seen as new as opposed to established.

Can I turn this iptables rule off for outgoing connections on the Blue eth2 
interface? Presumably if limited to outgoing through eth2 this would be safe? 
If so, what iptables rule should I use?

thanks
Rich

On Saturday 27 Nov 2004 18:36, Richard Booth wrote:
> Hi
>
> Running 1.4.0 and 1.4.1 I've noticed every now and then "NEW not SYN?" from
> the local green or blue ip addresses to ipcop gateway on port 800
> (MDBS_DAEMON).
>
> I think port 800 is the proxy and I have a transparent proxy enabled for
> green and blue, but I don't understand why the local addresses from green
> and blue were stopped in the firewall log.
>
> Any ideas?
>
> thanks
> Rich

On Tue, Nov 30, 2004 at 10:15:30AM -0800, Darren Critchley wrote:
> For your information:
> 
> LFS 5.1.1 will not compile with Fedora Core 2, I do not know if this will
> apply to building Ipcop, but I thought I would mention it. I assume the same
> would apply to Fedora Core 3.

I've had no problems compiling any of the 1.4.x series on FC2 or FC3.

Alan.

For your information:

LFS 5.1.1 will not compile with Fedora Core 2, I do not know if this will
apply to building Ipcop, but I thought I would mention it. I assume the same
would apply to Fedora Core 3.

Darren

Le Mardi 30 Novembre 2004 05:34, Wil Cooley a =E9crit :
If you start IP address with 0, sometimes (I'm sure),
or always (less sure) number is read as octal.

I waste some hours finding a bug some years ago with this.


Try ping under linux.

Bye

=46ranck

On Mon, Nov 29, 2004 at 08:34:50PM -0800, Wil Cooley wrote:
> 
> Looking over the code in dmzholes.cgi, it's clear that it allows only
> IP-to-IP rules, rather than IP net-to-IP net, which would be far
> preferable.  As it is, I have to use CUSTOM* chains to do basic things
> like allowing SSH from BLUE to GREEN.  Similarly for wireless.cgi--you'd
> think you could just permit access for the whole of the blue network if
> you intended to run an open access point.
> 
> Looking over the valid* functions header.pl, they're a bit... lame. 
> Unless I am misunderstanding, it oddly checks that quads do not start with
> '0', which seems pointless, considering that it's perfectly valid to write
> '192.168.002.010'.  There are also more exotic formats that are generally
> acceptable but clearly not tested for, like 0xffffff00 for
> 255.255.255.0, 10.1 for 10.0.0.1, or 192.168.2 for 192.168.2.0/24.  It
> would seem to me that Net::Netmask would be better for handling this sort
> of thing; since it appears that header.pl is bound to be rewritten anyway
> (unless I am mistaken about the "Lose final SmoothWall code" from the
> roadmap).
>
> Are there any any coding standards I should follow if I wish to submit a
> patch?  Are there UML rootfses for both a build environment and
> installed system?

Just ensure you send a diff with '-u' to make it easy to read.

Alan.

Tom, I like the banners.  Thanks for making something I can use.

Doug


On Tue, 23 Nov 2004 04:46:01 +0100, Ronnie Andreasen <ip...@ro...> wrote:
> Hi,
> 
> I have a request that others might need as well :-)
> 
> Could someone please update the CD labels for IPCop at http://www.ipcop.org/cgi-bin/twiki/view/IPCop/IPCopArt with new version numbers?
> 
> Or even better create new labels in an editable high-resolution format like Photoshop or Coreldraw?
> 
> --
> Best Regards
>   Ronnie
> 
> *********** REPLY SEPARATOR  ***********
> 
> 
> 
> On 22-11-2004 at 22:08 Tom Eichstaedt wrote:
> 
> >Hello,
> >
> >I've created a banner ("IPcop V1.4 design", 468x60 Pixel, 6.265 Byte)
> >for your webpages and published it at IPCop.org:
> >http://www.ipcop.org/modules.php?op=modload&name=phpWiki&file=index&pagename=IPCopArt
> >
> >May be it's useful for some of you. Let me know if you like it (or not).
> >
> >Best regards,
> >-Tom-
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://productguide.itmanagersjournal.com/
> >_______________________________________________
> >IPCop-devel mailing list
> >IPC...@li...
> >https://lists.sourceforge.net/lists/listinfo/ipcop-devel
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

64-bit userland in Gentoo and other linux sun4u distros definitely
doesn't work.  You absolutely need to specifiy 32-bit, unless things
have changed very recently.

Have you checked emerge to see what glibc version you have installed,
and what version is expected by IPCop?  On my sparcs and hppas running
gentoo, I frequently had problems with "old" compilers and libraries.

Sorry I can't be of more help, but maybe that will point you in the
right direction.

Doug


On Mon, 29 Nov 2004 09:51:02 +0100 (CET), y b <yb...@ya...> wrote:
> Hi,
>=20
> thx for help, here are the results:
> i tried -m32 but the problem is the same
> i tried -mtune-ultrasparc but then nothing compiles
>=20
> i do not know how to determine if Gentoo's libc
> libraries was compiled as 32 bit or 64 bit :-( . i
> just know they 've been compiled with "-O2
> -mcpu=3Dultrasparc  -pipe"
>=20
> YbbY
>=20
>  --- John Edwards <sh...@co...> a
> =E9crit :
>=20
>=20
> > On Fri, Nov 26, 2004 at 05:49:10PM +0100, y b wrote:
> > > Hi all,
> > >
> > > i got gentoo running on a Sun Ultra 10. i'd like
> > to
> > > try to build IPCOP on it because the little Ultra
> > 5
> > > sitting next the Ultra 10 would be a perfect IPCOP
> > box
> > > ;-)
> > >
> > > after a few modifications :
> > >
> > > # diff make.sh make.sh.orig
> > > 50,54d49
> > > <   elif [ 'sparc64' =3D $MACHINE ]; then
> > > <       echo "`date -u '+%b %e %T'`: sparc YO! " |
> > tee
> > > -a $LOGFILE
> > > <       BUILDTARGET=3Dsparc64-unknown-linux-gnu
> > > <       CFLAGS=3D"-O2 -mcpu=3Dultrasparc  -pipe"
> > > <       CXXFLAGS=3D"-O2 -mcpu=3Dultrasparc  -pipe"
> > >
> > > the build process stops on gcc :
> > <snip>
> >
> > > /tools/sparc64-unknown-linux-gnu/bin/ld: skipping
> > incompatible /usr/lib/libc.so when searching for -lc
> > <snip>
> >
> > I think this incompatiblity is the start of your
> > problems, and sounds
> > like a 32 vs 64 bit issue. I believe that if you
> > give the CPU type as
> > ultrasparc then gcc assumes that you want 64 bit
> > code (though I'm not
> > 100% as I don't know which version of gcc you are
> > using).
> >
> > So was Gentoo's libc libraries compiled as 32 bit or
> > 64 bit ?
> >
> >
> > Have a look at the documentation on
> > http://gcc.gnu.org/ for lots of
> > options on Sparc CPUs and 32 & 64 bit compiling.
> >
> > I suspect that very little of the IPCop code is 64
> > bit clean, so
> > consider compiling 32 bit code with the'-m32' gcc
> > option (it's not
> > too much slower for most programs).
> >
> > Another gcc option you may want to consider for a
> > UltraSPARC only
> > build is '-mtune-ultrasparc', which sets the
> > instruction scheduling
> > for that particular chip.
> >
> > If you are still getting problems then a search on
> > Google for the
> > parts of above error message from ld may bring some
> > clues.
> >
> >
> > References:
> >
> >
> http://gcc.gnu.org/onlinedocs/gcc-3.3.4/gcc/SPARC-Options.html
> >   http://www.osnews.com/printer.php?news_id=3D6136
> >
> >
> > --
> >
> #---------------------------------------------------------#
> > |       John Edwards    Email: Joh...@uk...
> >      |
> > |
> >      |
> > | A. Because it breaks the logical sequence of
> > discussion |
> > | Q. Why is top posting bad ?
> >      |
> >
> #---------------------------------------------------------#
> >
>=20
>                =20
> Vous manquez d'espace pour stocker vos mails ?
>=20
>=20
> Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
> Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
>=20
> Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouveau=
t=E9s pour dialoguer instantan=E9ment avec vos amis. A t=E9l=E9charger grat=
uitement sur http://fr.messenger.yahoo.com
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

Looking over the code in dmzholes.cgi, it's clear that it allows only
IP-to-IP rules, rather than IP net-to-IP net, which would be far
preferable.  As it is, I have to use CUSTOM* chains to do basic things
like allowing SSH from BLUE to GREEN.  Similarly for wireless.cgi--you'd
think you could just permit access for the whole of the blue network if
you intended to run an open access point.

Looking over the valid* functions header.pl, they're a bit... lame. 
Unless I am misunderstanding, it oddly checks that quads do not start with
'0', which seems pointless, considering that it's perfectly valid to write
'192.168.002.010'.  There are also more exotic formats that are generally
acceptable but clearly not tested for, like 0xffffff00 for
255.255.255.0, 10.1 for 10.0.0.1, or 192.168.2 for 192.168.2.0/24.  It
would seem to me that Net::Netmask would be better for handling this sort
of thing; since it appears that header.pl is bound to be rewritten anyway
(unless I am mistaken about the "Lose final SmoothWall code" from the
roadmap).

Are there any any coding standards I should follow if I wish to submit a
patch?  Are there UML rootfses for both a build environment and
installed system?

Wil
-- 
Wil Cooley                                 wc...@na...
Naked Ape Consulting                        http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *

Dear list

I am determined to run OpenVPN on ipcop 1.4.x as a site-to-site link between
IPCop and other sites.

I have got an openVPN binary running on ipcop, and have successfully
established a tunnel between two IPCop boxes.

The interface is presented as a routed subnet connected to a new virtual
interface tun1. However I have been running into problems with iptables
rules blocking traffic in and out of the virtual interface.

My question is, how can I modify IPCop to assign tun1 to $ORANGE_DEV? Where
is $ORANGE_DEV etc defined?

(I presume that routing on ipcop is set up such that boxes on green can
route to the orange subnet?)

Cheers
Tom

On Mon, Nov 29, 2004 at 01:33:15PM -0800, Stuart Whitman wrote:
> Hello,
> 
> After upgrading to 1.4.1 I noticed that DNS on the
> green network did not work for requests of the type
> host.mydomain for computers that were served an ip
> from dhcp. Hosts in the host file worked fine. Request
> using only the host (leaving off mydomain) worked.
> 
> I discovered that the dnsmasq program was not started
> with the -s mydomain option.
> 
> Further investigation led me to the rc.updatered
> script which sets the -s option when DOMAIN_NAME is
> set.
> 
> /var/ipcop/dhcp/settings file contains entries for
> DOMAIN_NAME_GREEN and DOMAIN_NAME_BLUE, but not for
> DOMAIN_NAME.

Thanks for catching that Stu.

Applied to CVS for the 1.4.2 update.

Alan.

Hello,

After upgrading to 1.4.1 I noticed that DNS on the
green network did not work for requests of the type
host.mydomain for computers that were served an ip
from dhcp. Hosts in the host file worked fine. Request
using only the host (leaving off mydomain) worked.

I discovered that the dnsmasq program was not started
with the -s mydomain option.

Further investigation led me to the rc.updatered
script which sets the -s option when DOMAIN_NAME is
set.

/var/ipcop/dhcp/settings file contains entries for
DOMAIN_NAME_GREEN and DOMAIN_NAME_BLUE, but not for
DOMAIN_NAME.

Stu


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

on 29/11/04 12:24 pm, Eric Oberlander at er...@ob... wrote:

> on 29/11/04 11:18 am, ca...@sa... at ca...@sa...
> wrote:
> 
>> Hi,
>> Mac O/s is not the only one that displays this hiding of the host name none
>> of my Linux boxes (Debian Woody or Mandrake 9. ) show up either I only know
>> the connections are kosher because of the MAC  I.d's.
>> Some thing seems to be very wrong with IPCOP's host name collection routine.

I've discovered the Mac OS X problem is just that, a Mac OS X problem. And
there is a solution.

To get a 'client-hostname' from a Mac running OS X 10.2.8 to appear in the
/var/state/dhcp/dhcp.leases file, and therefore to appear in IPCop's list of
current dynamic leases, the 'Computer Name' in the 'System Preferences >
Sharing' Panel must be a single word. Spaces and underscores will prevent
the hostname being stored in the dhcp.leases file. Hyphens (-) are OK.

Putting a name in the 'DHCP Client ID' field of the 'System Preferences >
Networking' Panel, when using DHCP, results in the name being stored in
IPCop's /var/state/dhcp/dhcp.leases file as a 'uid' record, and not a
'client-hostname'.

Regards.

Eric

on 29/11/04 11:18 am, ca...@sa... at ca...@sa...
wrote:

> Hi,
> Mac O/s is not the only one that displays this hiding of the host name none
> of my Linux boxes (Debian Woody or Mandrake 9. ) show up either I only know
> the connections are kosher because of the MAC  I.d's.
> Some thing seems to be very wrong with IPCOP's host name collection routine.

Are your Linux DHCP clients offering IPCop a hostname? With dhcpcd I seem to
recall that it has an '-h hostname' option, which I got to work on a Redhat
system, many moons ago.

You could also try patching your /var/ipcop/header.pl file with the attached
header.pl.diff file. I was able to extract the Mac OSX hostnames from the
uid field within the DHCP record. It doesn't break Suse 9.1, but I haven't
tested it on other Linux systems yet, so it might be an 'Ugly Hack'...
 
> By the way has any one come up with a fix for the graph menu header wrong
> hiliighting routine yet?  Posted as small bug in gui

Yes, I think that is fixed in CVS. Download a new copy of header.pl from CVS
and try it out (URL link should be all on one line, obviously):

http://cvs.sourceforge.net/viewcvs.py/ipcop/ipcop/config/cfgroot/header.pl?r
ev=1.39&view=log

You'll need to alter the VERSION and CONFIG_ROOT variables within it to make
it run. Change 'VERSION' to '1.4.1' and 'CONFIG_ROOT' to '/var/ipcop'

However, this may not be the final fix, as Alan has pointed out that it
stops menu highlighting when records are sorted on the dhcp.cgi page. It's
not quite right, but it's less of a problem, to my mind :)

Regards.

Eric

 Monday 29 Nov 2004 8:41 am, Eric Oberlander wrote:
> > hello again...
> >
> > not a high priority problem but on out small MacOS 10.3.6 network the
> > hostnames of the macs do not show up in the dynamic leases part of the
> > network status page on IPCOP 1.4.1.
> >
> > Each mac is assigned a correct IP address and these and the MAC
> > addresses show correctly but no hostname..
> >
> > The macs mount their home directories using NFS and are authenticated
> > using NIS. I guess this must be the reason since our two laptops and
> > WK2 machines do show their names OK and they are not using NFS or NIS..
> >
 > thanks
> >
> > adrian

> I've noticed the same behaviour with Mac OSX. Looking inside the
> /var/state/dhcp/dhcpd.leases file, the first example record is from an
> iBook running Mac OS 10.2.8, and the second record is from a G3 running Mac
> OS 9.0
>
> lease 192.168.1.17 {
>   starts 1 2004/11/29 07:47:37;
>   ends 1 2004/11/29 09:47:37;
>   binding state active;
>   next binding state free;
>   hardware ethernet 00:00:00:00:00:00;
>   uid "\000iBook";
> }
>
> lease 192.168.1.18 {
>   starts 1 2004/11/29 08:17:57;
>   ends 1 2004/11/29 10:17:57;
>   binding state active;
>   next binding state free;
>   hardware ethernet 00:00:00:00:00:00;
>   uid "\000G3";
>   client-hostname "G3 Desktop";
> }
>
> It looks like there's a communication breakdown between MAC OSX's dhcpcd
> and IPCop's dhcpd. Can the MAC OSX dhcp client be forced to provide a
> hostname?
>
> Eric
Hi,
 Mac O/s is not the only one that displays this hiding of the host name none 
of my Linux boxes (Debian Woody or Mandrake 9. ) show up either I only know 
the connections are kosher because of the MAC  I.d's.
 Some thing seems to be very wrong with IPCOP's host name collection routine.

By the way has any one come up with a fix for the graph menu header wrong 
hiliighting routine yet?  Posted as small bug in gui 

 MTIA
-- 
TTFN
 Caparo
  www.saltmine.org.uk

Hi, 

thx for help, here are the results:
i tried -m32 but the problem is the same
i tried -mtune-ultrasparc but then nothing compiles

i do not know how to determine if Gentoo's libc
libraries was compiled as 32 bit or 64 bit :-( . i
just know they 've been compiled with "-O2
-mcpu=ultrasparc  -pipe"

YbbY



 --- John Edwards <sh...@co...> a
écrit : 
> On Fri, Nov 26, 2004 at 05:49:10PM +0100, y b wrote:
> > Hi all,
> > 
> > i got gentoo running on a Sun Ultra 10. i'd like
> to
> > try to build IPCOP on it because the little Ultra
> 5
> > sitting next the Ultra 10 would be a perfect IPCOP
> box
> > ;-) 
> > 
> > after a few modifications :
> > 
> > # diff make.sh make.sh.orig
> > 50,54d49
> > <   elif [ 'sparc64' = $MACHINE ]; then
> > <       echo "`date -u '+%b %e %T'`: sparc YO! " |
> tee
> > -a $LOGFILE
> > <       BUILDTARGET=sparc64-unknown-linux-gnu
> > <       CFLAGS="-O2 -mcpu=ultrasparc  -pipe"
> > <       CXXFLAGS="-O2 -mcpu=ultrasparc  -pipe"
> > 
> > the build process stops on gcc :
> <snip> 
> 
> > /tools/sparc64-unknown-linux-gnu/bin/ld: skipping
> incompatible /usr/lib/libc.so when searching for -lc
> <snip> 
> 
> I think this incompatiblity is the start of your
> problems, and sounds 
> like a 32 vs 64 bit issue. I believe that if you
> give the CPU type as 
> ultrasparc then gcc assumes that you want 64 bit
> code (though I'm not 
> 100% as I don't know which version of gcc you are
> using).
> 
> So was Gentoo's libc libraries compiled as 32 bit or
> 64 bit ?
> 
> 
> Have a look at the documentation on
> http://gcc.gnu.org/ for lots of 
> options on Sparc CPUs and 32 & 64 bit compiling.
> 
> I suspect that very little of the IPCop code is 64
> bit clean, so 
> consider compiling 32 bit code with the'-m32' gcc
> option (it's not 
> too much slower for most programs).
> 
> Another gcc option you may want to consider for a
> UltraSPARC only 
> build is '-mtune-ultrasparc', which sets the
> instruction scheduling 
> for that particular chip.
> 
> If you are still getting problems then a search on
> Google for the 
> parts of above error message from ld may bring some
> clues.
> 
> 
> References:
>  
>
http://gcc.gnu.org/onlinedocs/gcc-3.3.4/gcc/SPARC-Options.html
>   http://www.osnews.com/printer.php?news_id=6136
> 
> 
> -- 
>
#---------------------------------------------------------#
> |       John Edwards    Email: Joh...@uk...  
>      |
> |                                                   
>      |
> | A. Because it breaks the logical sequence of
> discussion |
> | Q. Why is top posting bad ?                       
>      |
>
#---------------------------------------------------------#
>  


	

	
		
Vous manquez d’espace pour stocker vos mails ? 
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

As the previous attempt to send was rejected by kdi.ca (Darren was unknow
there ? )

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: "IPCOP devel" <ipc...@li...>
Cc: "Darren Critchley" <da...@kd...>
Sent: Sunday, November 28, 2004 2:24 AM
Subject: Is anyone else receiving duplicates over and over from ipcop-cvs?


> > I keep receiving the same updates from Gilles over and over again at
about
> 7
> > minute intervals, is anyone else experiencing this?
> >
> >
> >I am wondering if Sourceforge is broken or something.
> >
> > Thanks
> > Darren
>
> You are not alone
> I think it is MARC list wich is broken as the other list did not show the
> duplicate messages.
>
> https://sourceforge.net/mailarchive/forum.php?forum_id=4851
>
> I have send a message to MARC support when I understand the problem did
not
> stop by itself.
>

> I keep receiving the same updates from Gilles over and over again at about
7
> minute intervals, is anyone else experiencing this?
>
>
>I am wondering if Sourceforge is broken or something.
>
> Thanks
> Darren

You are not alone
I think it is MARC list wich is broken as the other list did not show the
duplicate messages.

https://sourceforge.net/mailarchive/forum.php?forum_id=4851

I have send a message to MARC support when I understand the problem did not
stop by itself.

Hi

Running 1.4.0 and 1.4.1 I've noticed every now and then "NEW not SYN?" from 
the local green or blue ip addresses to ipcop gateway on port 800
(MDBS_DAEMON).

I think port 800 is the proxy and I have a transparent proxy enabled for green 
and blue, but I don't understand why the local addresses from green and blue 
were stopped in the firewall log. 

Any ideas?

thanks
Rich

On Fri, Nov 26, 2004 at 05:49:10PM +0100, y b wrote:
> Hi all,
> 
> i got gentoo running on a Sun Ultra 10. i'd like to
> try to build IPCOP on it because the little Ultra 5
> sitting next the Ultra 10 would be a perfect IPCOP box
> ;-) 
> 
> after a few modifications :
> 
> # diff make.sh make.sh.orig
> 50,54d49
> <   elif [ 'sparc64' = $MACHINE ]; then
> <       echo "`date -u '+%b %e %T'`: sparc YO! " | tee
> -a $LOGFILE
> <       BUILDTARGET=sparc64-unknown-linux-gnu
> <       CFLAGS="-O2 -mcpu=ultrasparc  -pipe"
> <       CXXFLAGS="-O2 -mcpu=ultrasparc  -pipe"
> 
> the build process stops on gcc :
<snip> 

> /tools/sparc64-unknown-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
<snip> 

I think this incompatiblity is the start of your problems, and sounds 
like a 32 vs 64 bit issue. I believe that if you give the CPU type as 
ultrasparc then gcc assumes that you want 64 bit code (though I'm not 
100% as I don't know which version of gcc you are using).

So was Gentoo's libc libraries compiled as 32 bit or 64 bit ?


Have a look at the documentation on http://gcc.gnu.org/ for lots of 
options on Sparc CPUs and 32 & 64 bit compiling.

I suspect that very little of the IPCop code is 64 bit clean, so 
consider compiling 32 bit code with the'-m32' gcc option (it's not 
too much slower for most programs).

Another gcc option you may want to consider for a UltraSPARC only 
build is '-mtune-ultrasparc', which sets the instruction scheduling 
for that particular chip.

If you are still getting problems then a search on Google for the 
parts of above error message from ld may bring some clues.


References:
  http://gcc.gnu.org/onlinedocs/gcc-3.3.4/gcc/SPARC-Options.html
  http://www.osnews.com/printer.php?news_id=6136


-- 
#---------------------------------------------------------#
|       John Edwards    Email: Joh...@uk...        |
|                                                         |
| A. Because it breaks the logical sequence of discussion |
| Q. Why is top posting bad ?                             |
#---------------------------------------------------------#

----- Original Message ----- 
From: "y b" <yb...@ya...>
To: <ipc...@li...>
Sent: Friday, November 26, 2004 5:49 PM
Subject: [IPCop-devel] try to build IPCOP on sparc64 - stopped on gcc


> Hi all,
>
> i got gentoo running on a Sun Ultra 10. i'd like to
> try to build IPCOP on it because the little Ultra 5
> sitting next the Ultra 10 would be a perfect IPCOP box
> ;-)
>
> after a few modifications :
>
> # diff make.sh make.sh.orig
> 50,54d49
> <   elif [ 'sparc64' = $MACHINE ]; then
> <       echo "`date -u '+%b %e %T'`: sparc YO! " | tee
> -a $LOGFILE
> <       BUILDTARGET=sparc64-unknown-linux-gnu
> <       CFLAGS="-O2 -mcpu=ultrasparc  -pipe"
> <       CXXFLAGS="-O2 -mcpu=ultrasparc  -pipe"
>
[ .. ]
The only info I know is for x86 in
http://archive.daniel-baumann.ch/linux-from-scratch/hints/crosscompiling-x86/crosscompiling-x86-5.1.1-1.txt
this should be already used in actual make.sh

My understanding on the error message is that 32 bit version is not
compatible with sparc64. Is it the case?
> libgcc/32/_bb.oS libgcc/32/__gcc_bcmp.oS
> /tools/sparc64-unknown-linux-gnu/bin/ld: skipping
> incompatible /usr/lib/libc.so when searching for -lc

I am not an expert in crosscompilation.
Even if it will take more time, why don't you try first to compile on the
same machine it will be used as it should be easier to set?

Hi Folks,

I have released a new ATM driver for the Pulsar (v4.0.18).

You can download the source from...

http://adsl4linux.no-ip.org/pulsar.html

I have also put up a precompiled version for IPCop 1.4 at...

http://adsl4linux.no-ip.org/download.html

This version has been tested with IPCop 1.4. I have not tested it with 
1.4.1 yet, but I expect that it should work fine.

Feedback appreciated.

Kind regards,

  - Guy.
------------------------------------------------------------------
Guy Ellis
gu...@tr...

Traverse Technologies
ABN 98 078 657 324
652 Smith St.,
Clifton Hill, Victoria, 3068
AUSTRALIA
http://www.traverse.com.au
Tel (+613) 9486 7775
Fax (+613) 9482 7754
Mobile 0419 398 234
------------------------------------------------------------------

Hi YbbY,

i have no solution for you, sorry ;-( I've tried the same, and my gcc
stops at a similar point as yours.
But i'm verry interested for a installation on an sparc-system! Isn't
there a developer who can help us? It is possible for me to give some
developers a 'ssh-account' on a ultra 5 with a preinstalled-linux
distribution (gentoo, debian,... ) is this a deal?

Regards, harry



On Fri, 2004-11-26 at 17:49, y b wrote:
> Hi all,
>=20
> i got gentoo running on a Sun Ultra 10. i'd like to
> try to build IPCOP on it because the little Ultra 5
> sitting next the Ultra 10 would be a perfect IPCOP box
> ;-)=20
>=20
> after a few modifications :
>=20
> # diff make.sh make.sh.orig
> 50,54d49
> <   elif [ 'sparc64' =3D $MACHINE ]; then
> <       echo "`date -u '+%b %e %T'`: sparc YO! " | tee
> -a $LOGFILE
> <       BUILDTARGET=3Dsparc64-unknown-linux-gnu
> <       CFLAGS=3D"-O2 -mcpu=3Dultrasparc  -pipe"
> <       CXXFLAGS=3D"-O2 -mcpu=3Dultrasparc  -pipe"
>=20
> the build process stops on gcc :
>=20
> mv libgcc/32/tmp-libgcc.map libgcc/32/libgcc.map
> rm -rf 32/libgcc.a
> ar  rc 32/libgcc.a libgcc/32/_muldi3.oS
> libgcc/32/_negdi2.oS libgcc/32/_lshrdi3.oS
> libgcc/32/_ashldi3.oS libgcc/32/_ashrdi3.oS
> libgcc/32/_ffsdi2.oS libgcc/32/_clz.oS
> libgcc/32/_cmpdi2.oS libgcc/32/_ucmpdi2.oS
> libgcc/32/_floatdidf.oS libgcc/32/_floatdisf.oS
> libgcc/32/_fixunsdfsi.oS libgcc/32/_fixunssfsi.oS
> libgcc/32/_fixunsdfdi.oS libgcc/32/_fixdfdi.oS
> libgcc/32/_fixunssfdi.oS libgcc/32/_fixsfdi.oS
> libgcc/32/_fixxfdi.oS libgcc/32/_fixunsxfdi.oS
> libgcc/32/_floatdixf.oS libgcc/32/_fixunsxfsi.oS
> libgcc/32/_fixtfdi.oS libgcc/32/_fixunstfdi.oS
> libgcc/32/_floatditf.oS libgcc/32/_clear_cache.oS
> libgcc/32/_trampoline.oS libgcc/32/__main.oS
> libgcc/32/_exit.oS libgcc/32/_absvsi2.oS
> libgcc/32/_absvdi2.oS libgcc/32/_addvsi3.oS
> libgcc/32/_addvdi3.oS libgcc/32/_subvsi3.oS
> libgcc/32/_subvdi3.oS libgcc/32/_mulvsi3.oS
> libgcc/32/_mulvdi3.oS libgcc/32/_negvsi2.oS
> libgcc/32/_negvdi2.oS libgcc/32/_ctors.oS
> libgcc/32/_stack_smash_handler.oS libgcc/32/_divdi3.oS
> libgcc/32/_moddi3.oS libgcc/32/_udivdi3.oS
> libgcc/32/_umoddi3.oS libgcc/32/_udiv_w_sdiv.oS
> libgcc/32/_udivmoddi4.oS libgcc/32/_eprintf.oS
> libgcc/32/_bb.oS libgcc/32/__gcc_bcmp.oS
> /tools/sparc64-unknown-linux-gnu/bin/ld: skipping
> incompatible /usr/lib/libc.so when searching for -lc
> /tools/sparc64-unknown-linux-gnu/bin/ld: skipping
> incompatible /usr/lib/libc.a when searching for -lc
> /tools/sparc64-unknown-linux-gnu/bin/ld: cannot find
> -lc
> collect2: ld returned 1 exit status
> make[4]: *** [libgcc_s.so] Error 1
> make[4]: *** Waiting for unfinished jobs....
> if [ -f ranlib ] || ( [ sparc64-unknown-linux-gnu =3D
> sparc64-unknown-linux-gnu ] && [ -f /usr/bin/ranlib -o
> -f /bin/ranlib ] ) ; then \
>   ranlib 32/libgcc.a ; \
> else true; fi;
> make[4]: *** Waiting for unfinished jobs....
> make[4]: Leaving directory
> `/root/ipcop/build/usr/src/gcc-build/gcc'
> make[3]: *** [stmp-multilib] Error 2
> make[3]: Leaving directory
> `/root/ipcop/build/usr/src/gcc-build/gcc'
> make[2]: *** [stage1_build] Error 2
> make[2]: Leaving directory
> `/root/ipcop/build/usr/src/gcc-build/gcc'
> make[1]: *** [bootstrap] Error 2
> make[1]: Leaving directory
> `/root/ipcop/build/usr/src/gcc-build'
> make: *** [/root/ipcop/log/gcc-3.3.3-tools1] Error 2
>=20
>=20
> what's wrong?  am i trying the impossible?
>=20
> Regards,
> YbbY
>=20
>=20
>=20
>=20
>=20
> =09
>=20
> =09
> 	=09
> Vous manquez despace pour stocker vos mails ?=20
> Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
> Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
>=20
> Le nouveau Yahoo! Messenger est arriv=E9 ! D=E9couvrez toutes les nouve=
aut=E9s pour dialoguer instantan=E9ment avec vos amis. A t=E9l=E9charger =
gratuitement sur http://fr.messenger.yahoo.com
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users=
.
> Discover which products truly live up to the hype. Start reading now.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

> Stuart Whitman wrote:
> > Is there a way to have IPCOP monitor dynamic ip
> > addresses used in vpn connections and reset the
> > connection when they change?
> > 
> > I found a perl script called janus, but it relies
> on
> > x_leftdynamic and x_rightdynamic parameters being
> set
> > in the ipsec.conf file.
> > 

I did not get a lot of responses on this topic. I have
decided to put some effort into this as I have been
unable to connect from home at times when it has be
most inconvenient.

I assume this feature would be a nice to have and
would like to contribute the feature back to the IPCOP
development in the spirit of opensource and all that.

Which would be a better solution for ipcop?

1) Hack the Janus script to:
   a) Determine connections using dyn DNS by reading a
file
   b) Determine connections using dyn DNS from the
hostname
   c) Determine connections using dyn DNS from
connection names containing the suffix "_dyn"

2) change IPCOP to have a Dynamic DNS check box on the
add connection GUI which when checked inserts
x_leftdynamic or x_rightdynamic into the ipsec.conf
file.

Sorry to send an incomplete message earlier. I wanted
to tab, but it took me out of the editor box and I
ended up on the send button. Hitting return to try to
find the cursor caused the email to be sent.

Stu







		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

> Stuart Whitman wrote:
> > Is there a way to have IPCOP monitor dynamic ip
> > addresses used in vpn connections and reset the
> > connection when they change?
> > 
> > I found a perl script called janus, but it relies
> on
> > x_leftdynamic and x_rightdynamic parameters being
> set
> > in the ipsec.conf file.
> > 

I did not get a lot of responses on this topic. I have
decided to put some effort into this as I have been
unable to connect from home at times when it has be
most inconvenient.

I assume this feature would be a nice to have and
would like to contribute the feature back to the IPCOP
development in the spirit of opensource and all that.

Which would be a better solution for ipcop?

1) Hack the Janus script to:




		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

> If you are happy hacking your test system, log in as root and edit the
> /etc/issue file and change the 1.4.1 to 1.4.0 in the string. No guarantees,
> but it worked here :)
> Eric

Yes this worked, thanks.
Rich

On Friday 26 Nov 2004 13:50, you wrote:
> on 25/11/04 10:23 pm, Richard Booth at ric...@bi... wrote:
> > Hi
> >
> > I have 1.4.1 test 2 installed from an ISO image. Can I simply upgrade to
> > 1.4.1 proper using the web interface update or must I install the update
> > manually or reinstall ipcop with 1.4.1 iso?