ipcop-devel Mailing List for IPCop Firewall

Bugs item #1823741, was opened at 2007-10-31 17:17
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=1823741&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
Resolution: None
Priority: 5
Private: No
Submitted By: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.4.16 and RTL 8139D change IP address Problems

Initial Comment:
Hello,

Had a case where I had a firewall with Dual RTL 8139D based nics  where Red NIC would not properly go into set mode. The base install was 1.4.16. The confuration was red/green Everything seemed to go ok with the install the Red Ip Address was Eth1 and was a static IP address assigned by the ISP.

>From when the firewall was loaded to actually working date, the ISP changed and so I had to put in a new IP address.

I plugged in everything and stared it up.  The first thing I noticed is I did not get the  normal error message about not being able to contact the update list from the updater function.  I still needed to put in the new Ip address since it was a totally different ISP so no biggie but still odd.  I did a quick a ping test to the internal network and all was fine. The ping test to an external address did not work which was expected.  I did an ifconfig and it showed that both interfaces were up and running.

I then when in to setup and network configuration component. In the network it indiated that ETH1 was unset which is odd because ifconfig showed eth1 was running.  So I went and reallocated the nic on Red and then went and checked all settings for the Red interface. Nothing had changed and settings were correct, odd but ok and so I then went and put in the new correct settings.  I had the person looking over my back while I was doing this. Saved everthing and it did a sighup.  Still not connect. I restarted the fw and could not still connect. Went back into the setup and checked the network and it still indicated that Eth0 was unset and yet the ip address for the updated settings were correct and ifconfig showed the proper settings for eth0 and eth1 and LO.

Thinking I had a bad nic--it was used-- I went and got a new nic of the same type that was working for ETHO and swapped into the same slots. Upon reboot, I went into the setup and noticed now that the ETH1 was Set and exited setup  I could not still get out on the internet. Went back into Setup network and now ETH1 indicated it was unset. In each of the failure cases the Nic stats show a substantial number of RX but few TX for the Nic.  I even swaped cables and switch ports. Nothing worked.

So I went and reloaded but did not have a 1.4.16 copy in had, they lost it so I reloaded with 1.4.15 which I still had in my hot little hands. It all came up and was happy and could browse the internet.  I then applied 1.4.16 update via the UI.

One other oddity about all this, is that normally when you start IP COP it attempts to determine connectivity to the update site. In this case the message indicating that could not connect to update site never occurred on boot when in 1.4.16.

I have done a number of reconfigs in earlier versions of IPCOP pre .16 so this is the first time I have experienced this behavior. 

Sorry for the long post.

THanks for the great project.


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

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

Selon Johnny Miller <mi...@ci...>:

> Hey guys any plans on and add-on or build where you can assign nic cards
> manually?  I added a 4th nic card for orange and is hosed my setup.  The
> only way I could get back up was to remove the card and put everything back
> the way it was.
>
You always could assign NIC manually by not using probe and select manually a
driver.

I think setup could be made more effective by still displaying the previous
driver text on each interface(not the driver file name as it has been erased).
I would have to check that.

There is too one problem when during probe you use the cancel button.
Driver found is not affected to an interface and module remain loaded.
On next probe, the system find two interfaces and think they are owned by this
second driver found.
This is the simple case with one NIC matching a driver. But things become more
complicated with the case of multiples NIC using same driver.

Concerning MAC address, I know one patch has existed at a time but I have not
seen it.

Gilles

Hey guys any plans on and add-on or build where you can assign nic cards
manually?  I added a 4th nic card for orange and is hosed my setup.  The
only way I could get back up was to remove the card and put everything back
the way it was.

I love my ipcop.

Johnny Miller
millerj(at)cinci.rr.com
N8RTW
skype user: designwebs

On Wednesday 31 October 2007, Michael Rasmussen wrote:
> On Wed, 31 Oct 2007 04:31:17 -0400
>
> Ivan Kabaivanov <ch...@ya...> wrote:
> > Adding to the confussion is the fact that /dev/null is 0660 instead
> > of the correct 0666. The strange part is that in the build
> > directory /, /dev, and /dev/null have the correct 0755, 0755 and 0666
>
> Isn't udev activated in 1.9? As I recall it default permissions for
> device drivers in /dev, if udev is active, is 0660. The reason is that
> udev was design with that purpose to strengthen security vis-a-vis
> device drivers. Adding a new device driver should not automatically
> enable it for all current accounts but await sysadmin to manually add
> the relevant users to the device driver group.
>
> This means that to change behaviour of a newly created device driver
> you must provide an udev rules file.

Michael,

good point and I'll look into that.  Thanks for the hint.  I see a rule that 
sets /dev/console to 622, but no rule to set /dev/null to 777.  The only one 
is to set it to 666.

But still that does not explain the wrong permissions on / and /dev.

Ok, this is for now from me.  More later.

IvanK.

On Wednesday 31 October 2007, Olaf Westrik wrote:
> Ivan Kabaivanov wrote:
> > Olaf, you brought this up before.  Any ideas what's going on?  Is this
> > just busybox screwing up?  Should we try putting gnu tar back in the ISO?
>
> I've looked closely to /dev/null. Busybox is untarring correctly, so
> there is no need for GNU tar.
>
> If I saw correctly the problem lies in the /dev mounting done by the
> installer:
> /bin/mount -n -o bind /dev /harddisk/dev
>
> There might be some permission problem in Busybox, don't know exactly yet.
>
>
> Olaf

I'm doing a fresh install just to track this down.  After setup has finished 
and I get the congratulations screen, and all the filesystems have been 
unmounted, I don't reboot, but mount /dev/hda2 and / has the wrong 
permissions, /dev has the right permissions, /dev/null and /dev/console have 
the wrong permissions 777 and 622 (instead of 666 and 600).  However, just 
out of curiosity I checked my host system's permissions.  They are good for 
for / and /dev, but they have the wrong permissions for /dev/null 
and /dev/console -- 777 and 622.  So either the build directory gets the 
wrong permissions from my host, or the build is screwing up my host system.  
I'll have to check that later though.

IvanK.

On Wed, 31 Oct 2007 04:31:17 -0400
Ivan Kabaivanov <ch...@ya...> wrote:

> Adding to the confussion is the fact that /dev/null is 0660 instead
> of the correct 0666. The strange part is that in the build
> directory /, /dev, and /dev/null have the correct 0755, 0755 and 0666
Isn't udev activated in 1.9? As I recall it default permissions for
device drivers in /dev, if udev is active, is 0660. The reason is that
udev was design with that purpose to strengthen security vis-a-vis
device drivers. Adding a new device driver should not automatically
enable it for all current accounts but await sysadmin to manually add
the relevant users to the device driver group.

This means that to change behaviour of a newly created device driver
you must provide an udev rules file.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Q:	Are we not men?
A:	We are Vaxen.

Ivan Kabaivanov wrote:

> Olaf, you brought this up before.  Any ideas what's going on?  Is this just 
> busybox screwing up?  Should we try putting gnu tar back in the ISO?

I've looked closely to /dev/null. Busybox is untarring correctly, so 
there is no need for GNU tar.

If I saw correctly the problem lies in the /dev mounting done by the 
installer:
/bin/mount -n -o bind /dev /harddisk/dev

There might be some permission problem in Busybox, don't know exactly yet.


Olaf

-- 

A weizen a day helps keep the doctor away.

I can't see why nor how, but my installation ends up with /dev and / having 
1777 permissions.  This is a serious issue as anyone can create files in /dev 
and / (I tested it with a regular account).  Adding to the confussion is the 
fact that /dev/null is 0660 instead of the correct 0666. The strange part is 
that in the build directory /, /dev, and /dev/null have the correct 0755, 
0755 and 0666 respectively permissions and I can't find anywhere in lfs/* or 
the installer where we reset the permissions.

Olaf, you brought this up before.  Any ideas what's going on?  Is this just 
busybox screwing up?  Should we try putting gnu tar back in the ISO?

IvanK.

Gilles Espinasse wrote:

> I think it would be easier to have openswan modules include in the kernel
> (no dependencies, that's include). But treat package dependence is
> necessary.
> Having packages smaller create less requirements in term of available space
> during installation.
> But there is other solutions than to create many very small packages.
> Numerous small packages could need a longer time to unpack and install.

Packages will also complicate the dependencies and possible conflicts 
(versioning).

As it is now everything fits easily in 256 MB.
IMHO squeezing (by creating packages) creates more work and trouble than 
it is worth.


Olaf

-- 

A weizen a day helps keep the doctor away.

Ivan Kabaivanov wrote:

> then I think we should make prefetch prerequisite for build.  I'd like for 
> every script in lfs/ to be a single purpose script -- just do its own 
> package.  lfs/linux is now doing stuff that can and should be done in 
> lfs/openswan.  From my reading, it appears that we can treat the openswan 
> modules the way we treat the rest of the external kernel modules -- compiled 
> separately, after the kernel.

If I read correctly we need to patch and rebuild the kernel for NAT-T.
If we want to do things correctly that would mean build the kernel
first, later patch (for NAT-T) and rebuild.

Now that's a cleaner approach, but takes more time to build. I'm afraid
it is (unfortunately) better to keep linux and openswan together.


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Ivan Kabaivanov" <ch...@ya...>
To: <ipc...@li...>
Sent: Wednesday, October 31, 2007 3:56 AM
Subject: Re: [IPCop-devel] [Ipcop-svn] SF.net SVN: ipcop:
[575]ipcop/trunk/lfs


> On Tuesday 30 October 2007, Gilles Espinasse wrote:
> > I suspect that change is wrong when prefetch is not run because make.sh
run
> > lfs/linux before lfs/openswan
> > So patching the kernel will fail because patches are not yet loaded.
> >
> > Gilles
>
>
> Gilles,
>
> then I think we should make prefetch prerequisite for build.  I'd like for
> every script in lfs/ to be a single purpose script -- just do its own
> package.  lfs/linux is now doing stuff that can and should be done in
> lfs/openswan.  From my reading, it appears that we can treat the openswan
> modules the way we treat the rest of the external kernel modules -- 
compiled
> separately, after the kernel.
>
> What do you think?
>
I think making prefetch mandatory will not have a good result.
Think that you have run prefetch and compiled.
Then a package is upgraded (worst case for example openswan).
You would have to run prefetch again. That would imply running prefetch
before each build and that will not be good because of the time needed.
So previous linux state may not be nice looking code but was effective.
We could manage to read from lfs/linux the file names,URL and md5 inside
lfs/openswan.
I just fail for the md5 but do not take much effort but more important tasks
have to be done.

We have to think how we will create a kernel package and an openswan
package.
I am inclined to add a hook in lfs scripts to be executed after postbuild.
We have the list of files to be include, (possibly copy file to a temp dir
to strip files) and package.

I think it would be easier to have openswan modules include in the kernel
(no dependencies, that's include). But treat package dependence is
necessary.
Having packages smaller create less requirements in term of available space
during installation.
But there is other solutions than to create many very small packages.
Numerous small packages could need a longer time to unpack and install.

If we want to make a smaller footprint possible, we could manage to remove
drivers that will never be used on that particular machine ( other IDE and
SCSI drivers than the one used on this machine ). That should not be hard to
write a small script that remove unneed drivers after a kernel installation.
We may do the same for translations.
I am not inclined to do the same for NIC drivers as adding a NIC is and
should remain an easy task.

Gilles

On Tuesday 30 October 2007, Gilles Espinasse wrote:
> I suspect that change is wrong when prefetch is not run because make.sh run
> lfs/linux before lfs/openswan
> So patching the kernel will fail because patches are not yet loaded.
>
> Gilles


Gilles,

then I think we should make prefetch prerequisite for build.  I'd like for 
every script in lfs/ to be a single purpose script -- just do its own 
package.  lfs/linux is now doing stuff that can and should be done in 
lfs/openswan.  From my reading, it appears that we can treat the openswan 
modules the way we treat the rest of the external kernel modules -- compiled 
separately, after the kernel.

What do you think?

IvanK.






> ----- Original Message -----
> From: <ch...@us...>
> To: <ipc...@li...>
> Sent: Sunday, October 28, 2007 4:32 AM
> Subject: [Ipcop-svn] SF.net SVN: ipcop: [575] ipcop/trunk/lfs
>
> > Revision: 575
> >           http://ipcop.svn.sourceforge.net/ipcop/?rev=575&view=rev
> > Author:   chepati
> > Date:     2007-10-27 20:32:42 -0700 (Sat, 27 Oct 2007)
> >
> > Log Message:
> > -----------
> > Moved the openswan patch downloading to lfs/openswan.  Eventually I'd
> > like
>
> the only remaining openswan stuff in lfs/linux to be patching the kernel
> and the compilation of the openswan modules to be in lfs/openswan.
>

I suspect that change is wrong when prefetch is not run because make.sh run
lfs/linux before lfs/openswan
So patching the kernel will fail because patches are not yet loaded.

Gilles
----- Original Message ----- 
From: <ch...@us...>
To: <ipc...@li...>
Sent: Sunday, October 28, 2007 4:32 AM
Subject: [Ipcop-svn] SF.net SVN: ipcop: [575] ipcop/trunk/lfs


> Revision: 575
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=575&view=rev
> Author:   chepati
> Date:     2007-10-27 20:32:42 -0700 (Sat, 27 Oct 2007)
>
> Log Message:
> -----------
> Moved the openswan patch downloading to lfs/openswan.  Eventually I'd like
the only remaining openswan stuff in lfs/linux to be patching the kernel and
the compilation of the openswan modules to be in lfs/openswan.
>
> Modified Paths:
> --------------
>     ipcop/trunk/lfs/linux
>     ipcop/trunk/lfs/openswan
>
> Modified: ipcop/trunk/lfs/linux
> ===================================================================
> --- ipcop/trunk/lfs/linux 2007-10-27 18:19:42 UTC (rev 574)
> +++ ipcop/trunk/lfs/linux 2007-10-28 03:32:42 UTC (rev 575)
> @@ -53,9 +53,6 @@
>  # Top-level Rules
>
############################################################################
###
>  objects =$(DL_FILE) \
> - $(OPENSWAN).tar.gz \
> - $(OPENSWAN).kernel-2.6-natt.patch.gz \
> - $(OPENSWAN).kernel-2.6-klips.patch.gz \
>   $(IPTABLES).tar.bz2 \
>   patch-o-matic-ng-20070405.tar.bz2 \
>   grsecurity-2.1.10-2.6.19.2-200701222307.patch.gz \
> @@ -63,18 +60,12 @@
>
>  $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
>  patch-$(PATCHLEVEL).bz2 = $(DL_FROM)/patch-$(PATCHLEVEL).bz2
> -$(OPENSWAN).tar.gz = http://www.openswan.org/download/$(OPENSWAN).tar.gz
> -$(OPENSWAN).kernel-2.6-natt.patch.gz =
http://www.openswan.org/download/$(OPENSWAN).kernel-2.6-natt.patch.gz
> -$(OPENSWAN).kernel-2.6-klips.patch.gz =
http://www.openswan.org/download/$(OPENSWAN).kernel-2.6-klips.patch.gz
>  patch-o-matic-ng-20070405.tar.bz2 =
http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070405.tar.bz2
>  $(IPTABLES).tar.bz2 =
http://ftp.netfilter.org/pub/iptables/$(IPTABLES).tar.bz2
>  grsecurity-2.1.10-2.6.19.2-200701222307.patch.gz =
http://www.grsecurity.net/grsecurity-2.1.10-2.6.19.2-200701222307.patch.gz
>
>  $(DL_FILE)_MD5 = 2e230d005c002fb3d38a3ca07c0200d0
>  patch-$(PATCHLEVEL).bz2_MD5 = a29ac92cd688d591afd3fec48905e329
> -$(OPENSWAN).tar.gz_MD5 = 845f12d80d443cfa1a52f2b53b987bee
> -$(OPENSWAN).kernel-2.6-natt.patch.gz_MD5 =
9ed50e640ed141edcb750dfb3f1eb087
> -$(OPENSWAN).kernel-2.6-klips.patch.gz_MD5 =
017559bab4803e15c409930ef3035921
>  patch-o-matic-ng-20070405.tar.bz2_MD5 = 9474544764312b5eba9bd4013aecf902
>  $(IPTABLES).tar.bz2_MD5 = 0a9209f928002e5eee9cdff8fef4d4b3
>  grsecurity-2.1.10-2.6.19.2-200701222307.patch.gz_MD5 =
718ccce29ce12064673dbe8eb4752696
>
> Modified: ipcop/trunk/lfs/openswan
> ===================================================================
> --- ipcop/trunk/lfs/openswan 2007-10-27 18:19:42 UTC (rev 574)
> +++ ipcop/trunk/lfs/openswan 2007-10-28 03:32:42 UTC (rev 575)
> @@ -47,11 +47,17 @@
>  # Top-level Rules
>
############################################################################
###
>
> -objects = $(DL_FILE)
> +objects = $(DL_FILE) \
> + $(THISAPP).kernel-2.6-natt.patch.gz \
> + $(THISAPP).kernel-2.6-klips.patch.gz
>
>  $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
> +$(THISAPP).kernel-2.6-natt.patch.gz =
http://www.openswan.org/download/$(THISAPP).kernel-2.6-natt.patch.gz
> +$(THISAPP).kernel-2.6-klips.patch.gz =
http://www.openswan.org/download/$(THISAPP).kernel-2.6-klips.patch.gz
>
> -$(DL_FILE)_MD5 = 845f12d80d443cfa1a52f2b53b987bee
> +$(DL_FILE)_MD5 = 845f12d80d443cfa1a52f2b53b987bee
> +$(THISAPP).kernel-2.6-natt.patch.gz_MD5 =
9ed50e640ed141edcb750dfb3f1eb087
> +$(THISAPP).kernel-2.6-klips.patch.gz_MD5 =
017559bab4803e15c409930ef3035921
>
>  install : $(TARGET)

Ivan,


> For starters, you will no longer see skipped packages for architectures other than the one on which you're compiling.

Good, I think we should do the same with prefetch.
Or maybe even better, prefetch should not skip. Then you'd be able to 
have 1 cache that can be used across architectures.


> Let me know if you don't like this.  This is just a first attempt.  We can clearly improve on it.

I like it ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

On Saturday 27 October 2007, Olaf Westrik wrote:
> Hi Ivan,
>
> > Revision: 572
> >           http://ipcop.svn.sourceforge.net/ipcop/?rev=572&view=rev
> > Author:   chepati
> > Date:     2007-10-27 10:58:06 -0700 (Sat, 27 Oct 2007)
> >
> > Log Message:
> > -----------
> > One more instance of CONFIG_ROOT removed.  There's one more in this file
> > but for that we have to also fix the scripts in src/scripts
>
> The other is ok (I think), that is just the normal replacement into
> /var/ipcop
>
>
> Olaf

Olaf,

yes, you're right.  I forgot that we do store important configuration 
in /var/ipcop as well and these scripts reference those configuration files.

Thanks,
IvanK.

Hi Ivan,


> Revision: 572
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=572&view=rev
> Author:   chepati
> Date:     2007-10-27 10:58:06 -0700 (Sat, 27 Oct 2007)
> 
> Log Message:
> -----------
> One more instance of CONFIG_ROOT removed.  There's one more in this file but for that we have to also fix the scripts in src/scripts

The other is ok (I think), that is just the normal replacement into 
/var/ipcop


Olaf

-- 

A weizen a day helps keep the doctor away.

Feature Requests item #1821274, was opened at 2007-10-27 17:00
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=1821274&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: JGB (johngbell2)
Assigned to: Nobody/Anonymous (nobody)
Summary: remove smp kernels from non smp systems

Initial Comment:
Would it be possible to remove the smp kernels and modules automatically from non-smp systems?

On a minimum specification machine with CF card, the additional redundant files can cause disk space problems if not removed. At present I have to log in via ssh and delete them manually. I'm sure that there must be a number of less linux savvy firewall admins who would find this useful. 

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

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

Bugs item #1820077, was opened at 2007-10-25 10:59
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=1820077&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: General
Group: 1.4.11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: digitalfredy (digitalfredy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Secondary DNS not work

Initial Comment:
Secondary DNS not work, if using setup i configure in the first DNS any host without DNS server and put un the second DNS opendns 208.67.222.222 and made host i get connection timed out; noservers could be reached

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

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

Feature Requests item #1819957, was opened at 2007-10-25 22:49
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=1819957&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next major version
Status: Open
Priority: 5
Private: No
Submitted By: Scaredycrow (scaredycrow)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for VMware tools compatibility

Initial Comment:
Currently cannot install vmware tools on a vanilla IPCOP install. When attempting to run install configuration script receive error Ldd missing. 

Running Ipcop in a Virtual Machine allows IT admins to consolidate their servers, consume less space and energy. However performance is severely degraded, unless IPCOP can be installed. 

--Scaredycrow

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

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

Feature Requests item #1819680, was opened at 2007-10-25 02:21
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=1819680&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next release
Status: Open
Priority: 5
Private: No
Submitted By: yes (aadash486)
Assigned to: Nobody/Anonymous (nobody)
Summary: Adding HUAWEI E220 3G HSDPA USB MODEM support

Initial Comment:
Please could you add a driver to IPCOP to support HSDPA 3G mobile broadband. I'm sure this would be dearly appreciated by lots of people out there, who are switching to this from the even slower dial-up - as it allows coverage in places that fixed line broadband or wireless can't reach at present.

This is the information I have about it

Manufactured by HUAWEI Technologies Co. Ltd 

model: E220 

Device: 3G HSDPA USB modem

http://www.three.ie/ (a mobile telephone company here in Ireland) are behind it, and sell it to their customers so that they can access their mobile 3G broadband service    

You can get more information about it here


http://www.linux.ie/articles/tutorials/threeirelandUSBmodem.php 
 
and here

http://oozie.fm.interia.pl/pro/huawei-e220/index.html

and here

http://www.three.ie

Hope this information I have given is OK, And please consider adding it in your next release of IPCOP, in the "download driver section"

Really love the IPCOP PROJECT, and want to thank the guys behind it so very much :)
  

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

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

> Any peculiarities in your setup?  You mentioned before you were using sudo.  
> Please don't use sudo.  Use su - to login as root and run make.sh.  At this 
> point the build process still requires proper root access.  This may change 
> in the future, but for now you need to be logged in as root.
> 
> IvanK.

Just for the record:
I'm running Debian Etch (Stable) and did use sudo without problems already.
make.sh build runs without error and I get an ipcop-1.9.iso. At the last try (at
the weekend) I only had to change the snort URL to look into the ../old/.. dir.

Achim

On Monday 22 October 2007 17:39, Michael Rasmussen wrote:
> On Mon, 22 Oct 2007 17:30:44 -0400
>
> Ivan Kabaivanov <ch...@ya...> wrote:
> > This is really strange...  These two modules shouldn't be needed
> > until stage ipcop.  What was the error message and where did it
> > happen (what package and what stage)?
>
> Some of the lines are unfortunately very long, but a new line begins
> with either 5 or 6 digits (Line numbers from Vi).
>
> Errno.pm: (_build.base.log)
> 101513 make[3]: Leaving directory `/usr/src/autoconf-2.61/lib/m4sugar'
> 101514 autom4te_perllibdir='..'/lib
> AUTOM4TE_CFG='../lib/autom4te.cfg'         .       ./bin/autom4te -B
> '..'/lib -B '..'/lib         --language M4sh --cache ''
> --melt ./autoconf.as -o autoconf.in
> 101515 Can't locate Errno.pm in @INC (@INC
> contains: ../lib /tools_i486/lib/perl
> 5/5.8.8/i686-linux /tools_i486/lib/perl5/5.8.8 /tools_i486/lib/perl5/site
> _perl/5.8.8/i686-linux /tools_i486/lib/perl5/site_perl/5.8.8 /tools_i486/
> lib/perl5/site_perl .) at ../lib/Autom4te/XFile.pm line 90.
> 101516 BEGIN failed--compilation aborted at ../lib/Autom4te/XFile.pm
> line 90.
> 101517 Compilation failed in require at ../bin/autom4te line 44.
> 101518 BEGIN failed--compilation aborted at ../bin/autom4te line 44.
> 101519 make[2]: *** [autoconf.in] Error 1 101520 make[2]: Leaving
> directory `/usr/src/autoconf-2.61/bin'
> 101521 make[1]: *** [all-recursive] Error 1 101522 make[1]: Leaving
> directory `/usr/src/autoconf-2.61'
> 101523 make: *** [/usr/src/log_i486/02_base/autoconf-2.61] Error 2
> 101524 Oct 18 21:35:21: Building stage2
>
> Glob.pm: (_build.ipcop.log)
> 29227 patching file ./isdnlog/tools/isdnrate.c
> 29228 Hunk #1 succeeded at 304 (offset -5 lines).
> 29229 Hunk #2 succeeded at 313 (offset -5 lines).
> 29230 cd /usr/src/isdn4k-utils && sed -i 's%-lt 64%-lt 16%'
> scripts/makedev.sh 29231 cd /usr/src/isdn4k-utils/capi20 && rm -f lt*
> aclocal.m4
> 29232 cd /usr/src/isdn4k-utils/capi20 && aclocal
> 29233 Can't locate File/Glob.pm in @INC (@INC
> contains: /usr/share/automake-1.10      
> /tools_i486/lib/perl5/5.8.8/i686-linux /tools_i486/lib/perl5/5.8.8 /tools
> _i486/lib/perl5/site_perl/5.8.8/i686-linux /tools_i486/lib/perl5/site_perl 
>     /5.8.8 /tools_i486/lib/perl5/site_perl .) at /usr/bin/aclocal line
> 1017.
> 29234 BEGIN failed--compilation aborted at /usr/bin/aclocal line 1017.
> 29235 make: *** [/usr/src/log_i486/03_ipcop/isdn4k-utils.v3.2p1] Error
> 2
> 29236 Oct 19 07:48:08: Building stage3


Michael,

for some reason you're using the static perl built in stage toolchain.  This 
should have been overwritten by the perl installation in stage base.  Do you 
have a file log_i486/02_base/perl-5.8.8?  Search in that file for Errno.pm 
and Glob.pm

Also, have a look inside log_i486/_build.base.log and search for Errno.pm.  
This is what I have

        Making Errno (nonxs)
Writing Makefile for Errno
make[2]: Entering directory `/usr/src/perl-5.8.8/ext/Errno'
make[2]: Leaving directory `/usr/src/perl-5.8.8/ext/Errno'
make[2]: Entering directory `/usr/src/perl-5.8.8/ext/Errno'
../../miniperl "-I../../lib" "-I../../lib" Errno_pm.PL Errno.pm
cp Errno.pm ../../lib/Errno.pm
make[2]: Leaving directory `/usr/src/perl-5.8.8/ext/Errno'
make[1]: [extras.make] Error 1 (ignored)

        Everything is up to date. Type 'make test' to run test suite.

Any peculiarities in your setup?  You mentioned before you were using sudo.  
Please don't use sudo.  Use su - to login as root and run make.sh.  At this 
point the build process still requires proper root access.  This may change 
in the future, but for now you need to be logged in as root.

IvanK.

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBNb24s
IDIyIE9jdCAyMDA3IDE3OjMwOjQ0IC0wNDAwDQpJdmFuIEthYmFpdmFub3YgPGNoZXBhdGlAeWFo
b28uY29tPiB3cm90ZToNCg0KPiANCj4gVGhpcyBpcyByZWFsbHkgc3RyYW5nZS4uLiAgVGhlc2Ug
dHdvIG1vZHVsZXMgc2hvdWxkbid0IGJlIG5lZWRlZA0KPiB1bnRpbCBzdGFnZSBpcGNvcC4gIFdo
YXQgd2FzIHRoZSBlcnJvciBtZXNzYWdlIGFuZCB3aGVyZSBkaWQgaXQNCj4gaGFwcGVuICh3aGF0
IHBhY2thZ2UgYW5kIHdoYXQgc3RhZ2UpPw0KPiANCj4gDQpTb21lIG9mIHRoZSBsaW5lcyBhcmUg
dW5mb3J0dW5hdGVseSB2ZXJ5IGxvbmcsIGJ1dCBhIG5ldyBsaW5lIGJlZ2lucw0Kd2l0aCBlaXRo
ZXIgNSBvciA2IGRpZ2l0cyAoTGluZSBudW1iZXJzIGZyb20gVmkpLg0KDQpFcnJuby5wbTogKF9i
dWlsZC5iYXNlLmxvZykNCjEwMTUxMyBtYWtlWzNdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Vzci9z
cmMvYXV0b2NvbmYtMi42MS9saWIvbTRzdWdhcicNCjEwMTUxNCBhdXRvbTR0ZV9wZXJsbGliZGly
PScuLicvbGliDQpBVVRPTTRURV9DRkc9Jy4uL2xpYi9hdXRvbTR0ZS5jZmcnICAgICAgICAgLiAg
ICAgICAuL2Jpbi9hdXRvbTR0ZSAtQg0KJy4uJy9saWIgLUIgJy4uJy9saWIgICAgICAgICAtLWxh
bmd1YWdlIE00c2ggLS1jYWNoZSAnJw0KLSAtLW1lbHQgLi9hdXRvY29uZi5hcyAtbyBhdXRvY29u
Zi5pbiANCjEwMTUxNSBDYW4ndCBsb2NhdGUgRXJybm8ucG0gaW4gQElOQyAoQElOQw0KY29udGFp
bnM6IC4uL2xpYiAvdG9vbHNfaTQ4Ni9saWIvcGVybA0KNS81LjguOC9pNjg2LWxpbnV4IC90b29s
c19pNDg2L2xpYi9wZXJsNS81LjguOCAvdG9vbHNfaTQ4Ni9saWIvcGVybDUvc2l0ZQ0KX3Blcmwv
NS44LjgvaTY4Ni1saW51eCAvdG9vbHNfaTQ4Ni9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC44IC90
b29sc19pNDg2Lw0KbGliL3Blcmw1L3NpdGVfcGVybCAuKSBhdCAuLi9saWIvQXV0b200dGUvWEZp
bGUucG0gbGluZSA5MC4gDQoxMDE1MTYgQkVHSU4gZmFpbGVkLS1jb21waWxhdGlvbiBhYm9ydGVk
IGF0IC4uL2xpYi9BdXRvbTR0ZS9YRmlsZS5wbQ0KbGluZSA5MC4gDQoxMDE1MTcgQ29tcGlsYXRp
b24gZmFpbGVkIGluIHJlcXVpcmUgYXQgLi4vYmluL2F1dG9tNHRlIGxpbmUgNDQuIA0KMTAxNTE4
IEJFR0lOIGZhaWxlZC0tY29tcGlsYXRpb24gYWJvcnRlZCBhdCAuLi9iaW4vYXV0b200dGUgbGlu
ZSA0NC4NCjEwMTUxOSBtYWtlWzJdOiAqKiogW2F1dG9jb25mLmluXSBFcnJvciAxIDEwMTUyMCBt
YWtlWzJdOiBMZWF2aW5nDQpkaXJlY3RvcnkgYC91c3Ivc3JjL2F1dG9jb25mLTIuNjEvYmluJyAN
CjEwMTUyMSBtYWtlWzFdOiAqKiogW2FsbC1yZWN1cnNpdmVdIEVycm9yIDEgMTAxNTIyIG1ha2Vb
MV06IExlYXZpbmcNCmRpcmVjdG9yeSBgL3Vzci9zcmMvYXV0b2NvbmYtMi42MScgDQoxMDE1MjMg
bWFrZTogKioqIFsvdXNyL3NyYy9sb2dfaTQ4Ni8wMl9iYXNlL2F1dG9jb25mLTIuNjFdIEVycm9y
IDINCjEwMTUyNCBPY3QgMTggMjE6MzU6MjE6IEJ1aWxkaW5nIHN0YWdlMg0KDQpHbG9iLnBtOiAo
X2J1aWxkLmlwY29wLmxvZykNCjI5MjI3IHBhdGNoaW5nIGZpbGUgLi9pc2RubG9nL3Rvb2xzL2lz
ZG5yYXRlLmMNCjI5MjI4IEh1bmsgIzEgc3VjY2VlZGVkIGF0IDMwNCAob2Zmc2V0IC01IGxpbmVz
KS4NCjI5MjI5IEh1bmsgIzIgc3VjY2VlZGVkIGF0IDMxMyAob2Zmc2V0IC01IGxpbmVzKS4NCjI5
MjMwIGNkIC91c3Ivc3JjL2lzZG40ay11dGlscyAmJiBzZWQgLWkgJ3MlLWx0IDY0JS1sdCAxNiUn
DQpzY3JpcHRzL21ha2VkZXYuc2ggMjkyMzEgY2QgL3Vzci9zcmMvaXNkbjRrLXV0aWxzL2NhcGky
MCAmJiBybSAtZiBsdCoNCmFjbG9jYWwubTQgDQoyOTIzMiBjZCAvdXNyL3NyYy9pc2RuNGstdXRp
bHMvY2FwaTIwICYmIGFjbG9jYWwNCjI5MjMzIENhbid0IGxvY2F0ZSBGaWxlL0dsb2IucG0gaW4g
QElOQyAoQElOQw0KY29udGFpbnM6IC91c3Ivc2hhcmUvYXV0b21ha2UtMS4xMCAgICAgICAvdG9v
bHNfaTQ4Ni9saWIvcGVybDUvNS44LjgvaTY4Ni1saW51eCAvdG9vbHNfaTQ4Ni9saWIvcGVybDUv
NS44LjggL3Rvb2xzDQpfaTQ4Ni9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC44L2k2ODYtbGludXgg
L3Rvb2xzX2k0ODYvbGliL3Blcmw1L3NpdGVfcGVybCAgICAgIC81LjguOCAvdG9vbHNfaTQ4Ni9s
aWIvcGVybDUvc2l0ZV9wZXJsIC4pDQphdCAvdXNyL2Jpbi9hY2xvY2FsIGxpbmUgMTAxNy4gDQoy
OTIzNCBCRUdJTiBmYWlsZWQtLWNvbXBpbGF0aW9uIGFib3J0ZWQgYXQgL3Vzci9iaW4vYWNsb2Nh
bCBsaW5lIDEwMTcuDQoyOTIzNSBtYWtlOiAqKiogWy91c3Ivc3JjL2xvZ19pNDg2LzAzX2lwY29w
L2lzZG40ay11dGlscy52My4ycDFdIEVycm9yDQoyIA0KMjkyMzYgT2N0IDE5IDA3OjQ4OjA4OiBC
dWlsZGluZyBzdGFnZTMNCg0KDQotIC0tIA0KSGlsc2VuL1JlZ2FyZHMNCk1pY2hhZWwgUmFzbXVz
c2VuDQoNCkdldCBteSBwdWJsaWMgR251UEcga2V5czoNCm1pY2hhZWwgPGF0PiByYXNtdXNzZW4g
PGRvdD4gY2MNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206MTEzNzEvcGtzL2xvb2t1cD9v
cD1nZXQmc2VhcmNoPTB4RDNDOUEwMEUNCm1pciA8YXQ+IGRhdGFub20gPGRvdD4gbmV0DQpodHRw
Oi8va2V5c2VydmVyLnZlcmlkaXMuY29tOjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJjaD0w
eEU1MDFGNTFDDQptaXIgPGF0PiBtaXJhcyA8ZG90PiBvcmcNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVy
aWRpcy5jb206MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTNFODA5MTcNCi0gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCkhhbiBTb2xvOg0KCVdvbmRlcmZ1bCBnaXJsISBFaXRoZXIgSSdtIGdvaW5nIHRvIGtpbGwg
aGVyDQoJb3IgSSdtIGJlZ2lubmluZyB0byBsaWtlIGhlci4NCi0tLS0tQkVHSU4gUEdQIFNJR05B
VFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjYgKEdOVS9MaW51eCkNCg0KaUQ4REJRRkhI
UmltVkVyWVZlUG9DUmNSQW16WEFKMFdUcHM4NkJzNnNhL3ZlZ0pXSGg4MThKWWVvZ0NmUkdYYQ0K
SjdYL1dRQnYxMGlCQjVSS0h4bnp6NGc9DQo9ZnIvQg0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0t
LS0tDQo=

On Monday 22 October 2007 16:47, Michael Rasmussen wrote:
> Hi all,
>
> At last my mission succeeded:-)

Michael, good to hear.  And thanks for the report.

>
> Some comments:
> When building the build tree missed some important files in:
> build_i486/tools_i486. These were:
> - Errno.pm
> - Glob.pm (From File::Glob)

This is really strange...  These two modules shouldn't be needed until stage 
ipcop.  What was the error message and where did it happen (what package and 
what stage)?


> Had to download an install them manually. After that only one, but very
> annoying issue, were left to solve - glibc refused to build. The
> reason is the very last part where locales are generated because the
> input files has errors which causes localedef to issue warnings which
> again means that no files are created. Second, after generating the
> files make/bash complains about a missing file. Hard to find out which
> file, but must be related to forcing creation of the locale files. To
> be able to have glibc build automatically these changes was needed to
> lfs/glibc:
> 138: cd $(DIR_SRC)/glibc-build && localedef -c -i en_US -f ISO-8859-1
> en_US || true
> 139: cd $(DIR_SRC)/glibc-build && localedef -c -i en_US -f UTF-8
> en_US.utf8 || true
>
> I know, it is a dangerous hack, but it works:-)
>

yes, it is an ugly hack and we should spend the time to find the cause rather 
than bypass the behavior.  Is anyone else using debian sid who can try to 
duplicate this error?  If there isn't I'll have to find a spare machine to 
install sid and test.

> apart from the above I was not able to find snort-2.7.0.1 when I was
> running make.sh prefetch so I grabbed the lastest stable version 2.8.0.
> No warnings or error as a result, so I will make some test when I
> install 1.9 in my lab.

Thanks,
IvanK.

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpIaSBhbGws
DQoNCkF0IGxhc3QgbXkgbWlzc2lvbiBzdWNjZWVkZWQ6LSkNCg0KU29tZSBjb21tZW50czoNCldo
ZW4gYnVpbGRpbmcgdGhlIGJ1aWxkIHRyZWUgbWlzc2VkIHNvbWUgaW1wb3J0YW50IGZpbGVzIGlu
Og0KYnVpbGRfaTQ4Ni90b29sc19pNDg2LiBUaGVzZSB3ZXJlOg0KLSAtIEVycm5vLnBtDQotIC0g
R2xvYi5wbSAoRnJvbSBGaWxlOjpHbG9iKQ0KSGFkIHRvIGRvd25sb2FkIGFuIGluc3RhbGwgdGhl
bSBtYW51YWxseS4gQWZ0ZXIgdGhhdCBvbmx5IG9uZSwgYnV0IHZlcnkNCmFubm95aW5nIGlzc3Vl
LCB3ZXJlIGxlZnQgdG8gc29sdmUgLSBnbGliYyByZWZ1c2VkIHRvIGJ1aWxkLiBUaGUNCnJlYXNv
biBpcyB0aGUgdmVyeSBsYXN0IHBhcnQgd2hlcmUgbG9jYWxlcyBhcmUgZ2VuZXJhdGVkIGJlY2F1
c2UgdGhlDQppbnB1dCBmaWxlcyBoYXMgZXJyb3JzIHdoaWNoIGNhdXNlcyBsb2NhbGVkZWYgdG8g
aXNzdWUgd2FybmluZ3Mgd2hpY2gNCmFnYWluIG1lYW5zIHRoYXQgbm8gZmlsZXMgYXJlIGNyZWF0
ZWQuIFNlY29uZCwgYWZ0ZXIgZ2VuZXJhdGluZyB0aGUNCmZpbGVzIG1ha2UvYmFzaCBjb21wbGFp
bnMgYWJvdXQgYSBtaXNzaW5nIGZpbGUuIEhhcmQgdG8gZmluZCBvdXQgd2hpY2gNCmZpbGUsIGJ1
dCBtdXN0IGJlIHJlbGF0ZWQgdG8gZm9yY2luZyBjcmVhdGlvbiBvZiB0aGUgbG9jYWxlIGZpbGVz
LiBUbw0KYmUgYWJsZSB0byBoYXZlIGdsaWJjIGJ1aWxkIGF1dG9tYXRpY2FsbHkgdGhlc2UgY2hh
bmdlcyB3YXMgbmVlZGVkIHRvDQpsZnMvZ2xpYmM6DQoxMzg6IGNkICQoRElSX1NSQykvZ2xpYmMt
YnVpbGQgJiYgbG9jYWxlZGVmIC1jIC1pIGVuX1VTIC1mIElTTy04ODU5LTENCmVuX1VTIHx8IHRy
dWUgDQoxMzk6IGNkICQoRElSX1NSQykvZ2xpYmMtYnVpbGQgJiYgbG9jYWxlZGVmIC1jIC1pIGVu
X1VTIC1mIFVURi04DQplbl9VUy51dGY4IHx8IHRydWUgDQoNCkkga25vdywgaXQgaXMgYSBkYW5n
ZXJvdXMgaGFjaywgYnV0IGl0IHdvcmtzOi0pDQoNCmFwYXJ0IGZyb20gdGhlIGFib3ZlIEkgd2Fz
IG5vdCBhYmxlIHRvIGZpbmQgc25vcnQtMi43LjAuMSB3aGVuIEkgd2FzDQpydW5uaW5nIG1ha2Uu
c2ggcHJlZmV0Y2ggc28gSSBncmFiYmVkIHRoZSBsYXN0ZXN0IHN0YWJsZSB2ZXJzaW9uIDIuOC4w
Lg0KTm8gd2FybmluZ3Mgb3IgZXJyb3IgYXMgYSByZXN1bHQsIHNvIEkgd2lsbCBtYWtlIHNvbWUg
dGVzdCB3aGVuIEkNCmluc3RhbGwgMS45IGluIG15IGxhYi4NCg0KLSAtLSANCkhpbHNlbi9SZWdh
cmRzDQpNaWNoYWVsIFJhc211c3Nlbg0KDQpHZXQgbXkgcHVibGljIEdudVBHIGtleXM6DQptaWNo
YWVsIDxhdD4gcmFzbXVzc2VuIDxkb3Q+IGNjDQpodHRwOi8va2V5c2VydmVyLnZlcmlkaXMuY29t
OjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJjaD0weEQzQzlBMDBFDQptaXIgPGF0PiBkYXRh
bm9tIDxkb3Q+IG5ldA0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9v
a3VwP29wPWdldCZzZWFyY2g9MHhFNTAxRjUxQw0KbWlyIDxhdD4gbWlyYXMgPGRvdD4gb3JnDQpo
dHRwOi8va2V5c2VydmVyLnZlcmlkaXMuY29tOjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJj
aD0weEUzRTgwOTE3DQotIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCT0ZIIGV4Y3VzZSAjNDI0Og0KDQpvcGVyYXRpb24gZmFp
bGVkIGJlY2F1c2U6IHRoZXJlIGlzIG5vIG1lc3NhZ2UgZm9yIHRoaXMgZXJyb3IgKCMxMDE0KQ0K
LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuNiAoR05V
L0xpbnV4KQ0KDQppRDhEQlFGSEhReHBWRXJZVmVQb0NSY1JBbUZYQUo5R2dQUzRpWkRTdU1xeGxG
eTc0WllGaFhoelJBQ2duOVNtDQpZRVU4eVVkUWxoaXBoZk1uWENLVG54Zz0NCj14YklpDQotLS0t
LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==