ipcop-devel Mailing List for IPCop Firewall

Olaf Westrik schrieb:
> On 2010-04-30 23:09, Guenter wrote:
>> Hi,
>> I convinced a friend to participate with testing 1.9.x ... :)
>> now he went and changed all passwords via setup from shell. After that
>> he could no longer login to WebGUI as admin user. I examined a bit, and
>> it turned out that if you try to change the dialup user then this action
>> kills the admin user in /var/ipcop/auth/users; seems that setup does
>> with both the admin and the dialup password change create a new
>> /var/ipcop/auth/users file which is wrong; instead it should only change
>> the existing user entries, or add new entries, but never create a new
>> file ...
>
> Indeed.
>
> Funny thing is, a somewhat similar 'feature' exists in 1.4 and nobody
> ever noticed ;-)
hehe, think of the average user who always thinks the failure is with 
himself :) and then is to shy to report such as a bug - (s)he probably 
thinks (s)he gets an answer that (s)he is too stupid to change a 
password properly ....

Gün.

Hi Olaf,
Olaf Westrik schrieb:
> In changepw.cgi (same as in 1.4) we store admin and dial passwords
> differently.
> admin uses htpasswd -m for MD5 encryption
> dial uses htpasswd (without -m) which then uses crypt() for encryption.
>
> Apache seems to be happy with both methods, but is there any reason to
> do so?
> Should we use MD5 or crypt()? or SHA?
I would say SHA is the best choice in terms of portability and security ...

Gün.

In changepw.cgi (same as in 1.4) we store admin and dial passwords
differently.
admin uses htpasswd -m for MD5 encryption
dial uses htpasswd (without -m) which then uses crypt() for encryption.

Apache seems to be happy with both methods, but is there any reason to
do so?
Should we use MD5 or crypt()? or SHA?


Olaf

On 2010-04-30 23:09, Guenter wrote:
> Hi,
> I convinced a friend to participate with testing 1.9.x ... :)
> now he went and changed all passwords via setup from shell. After that 
> he could no longer login to WebGUI as admin user. I examined a bit, and 
> it turned out that if you try to change the dialup user then this action 
> kills the admin user in /var/ipcop/auth/users; seems that setup does 
> with both the admin and the dialup password change create a new 
> /var/ipcop/auth/users file which is wrong; instead it should only change 
> the existing user entries, or add new entries, but never create a new 
> file ...

Indeed.

Funny thing is, a somewhat similar 'feature' exists in 1.4 and nobody
ever noticed ;-)



Olaf

Hi,
I convinced a friend to participate with testing 1.9.x ... :)
now he went and changed all passwords via setup from shell. After that 
he could no longer login to WebGUI as admin user. I examined a bit, and 
it turned out that if you try to change the dialup user then this action 
kills the admin user in /var/ipcop/auth/users; seems that setup does 
with both the admin and the dialup password change create a new 
/var/ipcop/auth/users file which is wrong; instead it should only change 
the existing user entries, or add new entries, but never create a new 
file ...

Gün.

On 2010-04-28 08:04, Gilles Espinasse wrote:
> man install say -c is ignored.
> Should we keep that option and why?


I see no problem removing -c, versions 5.0 and 8.5 ignore that option (I
did not check all intermediate versions ;-)).

info install says:

`-c'
     Ignored; for compatibility with old Unix versions of `install'.

It is kept so no (old) Makefile breaks because of 'invalid option' error.


Olaf

man install say -c is ignored.
Should we keep that option and why?

Gilles

Olaf,
Am 23.04.2010 11:53, schrieb Olaf Westrik:
> On 2010-04-23 11:34, Guenter wrote:
>
>> Let's assume a fresh installation of 1.9.15 - what do I need to change
>> in order to access GREEN from OpenVPN?
>
> Simply save and activate the push route(s) in advanced server options.
> IIRC there are no routes pushed per default.
thanks! That works like a charm!

Gün.

On 2010-04-26 19:40, Eric Oberlander wrote:

> I'm editing the section of the Installation Manual that described how
> to recover or reset a lost root password. The technique used in v1.4.X
> no longer works as GRUB is not used in the new version.
> 
> Is there still a way to achieve this, or is it no longer possible in v1.9/2.0?

This should work:
at the boot menu, press <TAB> to drop into edit mode
at the end of the line add: init=/bin/bash
press <ENTER> to continue boot
when booting has finised enter: mount -o remount rw /
enter: passwd
enter the new password
repeat the new password
restart IPCop (ipcopreboot does not work and we neither have init nor
reboot ...)


Olaf


PS: <TAB> probably works on x86 only.

Il 26/04/2010 01:05, Guenter ha scritto:
>
> I've just updated to r4518 which is current revision at the time of
> writing this.
>    

Installed. Same configuration, same problem: no default gateway is being 
set. :(
I have to manually set it first to the public ip 79.37.65.52 and then to 
modem ip 192.168.1.1.

This is what I find in the RED system logs:

19:47:15 	dhcpcd 	version 5.2.2 starting
19:47:15 	dhcpcd: wan-1 	broadcasting for a lease
19:47:15 	dhcpcd: wan-1 	offered 79.37.65.52 from 192.168.1.1
19:47:15 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:47:15 	dhcpcd: wan-1 	checking for 79.37.65.52
19:47:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:47:21 	dhcpcd: wan-1: add_route 	No such process
19:47:23 	dhcpcd[] 	wan-1 has been configured with new IP=79.37.65.52
19:47:25 	dhcpcd 	forking to background
19:47:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:47:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:47:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:47:51 	dhcpcd: wan-1: add_route 	No such process
19:47:52 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:48:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:48:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:48:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:48:21 	dhcpcd: wan-1: add_route 	No such process
19:48:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:48:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:48:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:48:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:48:51 	dhcpcd: wan-1: add_route 	No such process
19:48:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:49:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:49:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:49:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:49:21 	dhcpcd: wan-1: add_route 	No such process
19:49:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:49:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:49:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:49:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:49:51 	dhcpcd: wan-1: add_route 	No such process
19:49:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:50:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:50:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:50:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:50:21 	dhcpcd: wan-1: add_route 	No such process
19:50:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:50:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:50:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:50:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:50:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:51:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:51:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:51:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:51:21 	dhcpcd: wan-1: add_route 	No such process
19:51:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:51:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:51:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:51:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:51:51 	dhcpcd: wan-1: add_route 	No such process
19:51:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:52:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:52:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:52:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:52:21 	dhcpcd: wan-1: add_route 	No such process
19:52:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:52:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:52:51 	dhcpcd: wan-1 	invalid UDP packet from 192.168.0.2
19:52:51 	dhcpcd: wan-1 	invalid UDP packet from 192.168.0.2
19:52:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:52:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:52:51 	dhcpcd: wan-1: add_route 	No such process
19:52:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:53:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:53:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:53:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:53:21 	dhcpcd: wan-1: add_route 	No such process
19:53:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:53:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:53:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:53:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:53:51 	dhcpcd: wan-1: add_route 	No such process
19:53:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:54:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:54:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:54:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:54:21 	dhcpcd: wan-1: add_route 	No such process
19:54:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:54:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:54:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:54:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:54:51 	dhcpcd: wan-1: add_route 	No such process
19:54:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:55:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:55:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:55:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:55:21 	dhcpcd: wan-1: add_route 	No such process
19:55:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:55:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:55:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:55:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:55:51 	dhcpcd: wan-1: add_route 	No such process
19:55:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:56:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:56:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:56:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:56:21 	dhcpcd: wan-1: add_route 	No such process
19:56:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:56:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:56:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:56:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:56:51 	dhcpcd: wan-1: add_route 	No such process
19:56:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:57:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:57:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:57:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:57:21 	dhcpcd: wan-1: add_route 	No such process
19:57:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:57:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:57:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:57:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:57:51 	dhcpcd: wan-1: add_route 	No such process
19:57:54 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:58:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:58:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:58:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:58:21 	dhcpcd: wan-1: add_route 	No such process
19:58:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:58:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:58:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:58:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:58:51 	dhcpcd: wan-1: add_route 	No such process
19:58:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:59:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:59:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:59:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:59:21 	dhcpcd: wan-1: add_route 	No such process
19:59:23 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
19:59:51 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
19:59:51 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
19:59:51 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
19:59:51 	dhcpcd: wan-1: add_route 	No such process
19:59:53 	dhcpcd[] 	wan-1 has been configured with same IP=79.37.65.52
20:00:21 	dhcpcd: wan-1 	renewing lease of 79.37.65.52
20:00:21 	dhcpcd: wan-1 	acknowledged 79.37.65.52 from 192.168.1.1
20:00:21 	dhcpcd: wan-1 	leased 79.37.65.52 for 60 seconds
20:00:21 	dhcpcd: wan-1: add_route 	No such process


Why does IpCop continously try to renew ip address and bind it to the red nic?
And why does it still try to add a default route even though I set it manually?

Regards.

Hi

I'm editing the section of the Installation Manual that described how
to recover or reset a lost root password. The technique used in v1.4.X
no longer works as GRUB is not used in the new version.

Is there still a way to achieve this, or is it no longer possible in v1.9/2.0?

Thanks

Eric

Il 26/04/2010 1.05, Guenter ha scritto:
>
> I've just updated to r4518 which is current revision at the time of
> writing this.
>    

I saw it. :)

Thanks a lot.

Regards..

Am 26.04.2010 07:47, schrieb David W Studeman:
> Thanks for the clarification, I'll take security over function anytime. I
> usually use the usb key during a fresh install personally but it's nice to
> know it can be done after the fact if you save the backup.key and sftp it
> back up. Of course this means that you will have had to configure the
> network again by hand just to be able to do that. It's easiest to use the
> usb stick during install in the first place.
agreed. Call it in forst place some old habit of me: with 1.4.x I then 
get a couple of errors with first boot since I get settings and calls 
from scripts to not yet installed addons like OpenVPN; so it makes more 
sense to first install any addons, and finally restore config with 
webgui; and restoring later via webgui isnt an issue for me since anyway 
I do right afterwards a reboot, so the network and everything else is 
re-configured (through the restored config) - no need to do anything by 
hand.

Gün.

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "Guenter" <li...@gk...>
> To: "David W Studeman" <avi...@ai...>; "IPCop devel"
> <ipc...@li...>
> Sent: Monday, April 26, 2010 3:31 AM
> Subject: Re: [IPCop-devel] question about backup / restore config
> 
> 
>> David,
>> David W Studeman schrieb:
>> > Guenter wrote:
>> >
>> >> Hi,
>> >> I really would like to get clearly explained how backup/restore is
>> >> supposed to work.
>> >> I can make a backup, and download it, fine.
>> >> I can upload a previously downloaded backup, and restore this backup
>> >> on the same machine, also fine.
>> >> I can export the backup key, fine; however what I miss is a way via
>> >> GUI how I can afterwards import this backup key into a fresh
>> >> installation.
>> >
>> > Via installer gui?
>> no, Web GUI I meant.
>>
>> Gün.
>>
> That's not simple in the security point of view.
> I agree that the actual situation is not the finest.
> I would prefer to have that interface in the installer for some reasons :
> - we can't allow you to import the backup key from web interface if a key
> is already present (and a key is created at first boot),
> - if you restore during installation from a backup crypted with backup
> key, you should be able to use that backup key to install the crypted
> backup.
> 
> Gilles
> 
> 
> We can't do that with Web GUI
> 
Thanks for the clarification, I'll take security over function anytime. I 
usually use the usb key during a fresh install personally but it's nice to 
know it can be done after the fact if you save the backup.key and sftp it 
back up. Of course this means that you will have had to configure the 
network again by hand just to be able to do that. It's easiest to use the 
usb stick during install in the first place.
-- 
Dave
http://www.raqcop.com

----- Original Message ----- 
From: "Guenter" <li...@gk...>
To: "David W Studeman" <avi...@ai...>; "IPCop devel"
<ipc...@li...>
Sent: Monday, April 26, 2010 3:31 AM
Subject: Re: [IPCop-devel] question about backup / restore config


> David,
> David W Studeman schrieb:
> > Guenter wrote:
> >
> >> Hi,
> >> I really would like to get clearly explained how backup/restore is
> >> supposed to work.
> >> I can make a backup, and download it, fine.
> >> I can upload a previously downloaded backup, and restore this backup on
> >> the same machine, also fine.
> >> I can export the backup key, fine; however what I miss is a way via GUI
> >> how I can afterwards import this backup key into a fresh installation.
> >
> > Via installer gui?
> no, Web GUI I meant.
>
> Gün.
>
That's not simple in the security point of view.
I agree that the actual situation is not the finest.
I would prefer to have that interface in the installer for some reasons :
- we can't allow you to import the backup key from web interface if a key is
already present (and a key is created at first boot),
- if you restore during installation from a backup crypted with backup key,
you should be able to use that backup key to install the crypted backup.

Gilles


We can't do that with Web GUI

Guenter wrote:

> David,
> David W Studeman schrieb:
>> Guenter wrote:
>> 
>>> Hi,
>>> I really would like to get clearly explained how backup/restore is
>>> supposed to work.
>>> I can make a backup, and download it, fine.
>>> I can upload a previously downloaded backup, and restore this backup on
>>> the same machine, also fine.
>>> I can export the backup key, fine; however what I miss is a way via GUI
>>> how I can afterwards import this backup key into a fresh installation.
>> 
>> Via installer gui?
> no, Web GUI I meant.
> 
> Gün.

Ok, I see exactly what you mean and yes there does seem to be a need to add 
the key import to the web gui. 
 
Dave
http://www.raqcop.com

David,
David W Studeman schrieb:
> Guenter wrote:
> 
>> Hi,
>> I really would like to get clearly explained how backup/restore is
>> supposed to work.
>> I can make a backup, and download it, fine.
>> I can upload a previously downloaded backup, and restore this backup on
>> the same machine, also fine.
>> I can export the backup key, fine; however what I miss is a way via GUI
>> how I can afterwards import this backup key into a fresh installation.
> 
> Via installer gui?
no, Web GUI I meant.

Gün.

Guenter wrote:

> Hi,
> I really would like to get clearly explained how backup/restore is
> supposed to work.
> I can make a backup, and download it, fine.
> I can upload a previously downloaded backup, and restore this backup on
> the same machine, also fine.
> I can export the backup key, fine; however what I miss is a way via GUI
> how I can afterwards import this backup key into a fresh installation.

Via installer gui?
 
> To save me further mess all the time I save /var/ipcop/backup/backup.key
> with scp, and restore this key on a fresh installation with scp before I
> try to restore the backup, and that works fine; however I would like to
> know if this is really the only way to restore a previously saved config
> from another machine, or if I'm missing something? Why dont we have a
> backup key import feature yet?
> 
> Gün.
> 
If you restore from a usb stick the only thing you need to have on it is the 
key and the dat file, here's where you may be going wrong if in fact you 
mean installer gui restore. You have to remove the time date stamp from your 
dat file name. Then usb restore works fine. The key itself does not need to 
be renamed. It will only look for the hostname dat file without the time 
date stamp as part of the file name.

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

Hi,
I really would like to get clearly explained how backup/restore is
supposed to work.
I can make a backup, and download it, fine.
I can upload a previously downloaded backup, and restore this backup on
the same machine, also fine.
I can export the backup key, fine; however what I miss is a way via GUI
how I can afterwards import this backup key into a fresh installation.

To save me further mess all the time I save /var/ipcop/backup/backup.key
with scp, and restore this key on a fresh installation with scp before I
try to restore the backup, and that works fine; however I would like to
know if this is really the only way to restore a previously saved config
from another machine, or if I'm missing something? Why dont we have a
backup key import feature yet?

Gün.

Michele schrieb:
> I'll try latest buid as soon as I can.
I've just updated to r4518 which is current revision at the time of
writing this.

Gün.

Il 26/04/2010 00:23, Guenter ha scritto:
>
> yes, but that also requires that you then use latest stuff build from
> svn ...; after 1.9.14 there were many major changes, f.e. new kernel,
> many packages updated - so things *might* have changed; therefore it is
> required that you use something newer than 1.9.14 since development
> advanced further ...
> feel free to use a relatively new build (though not latest) from my site:
> http://svwe20.itex.at/ipcop-development/
>    

Thank you very much.
I'll try latest buid as soon as I can.

Best regards.

Hi,
Michele schrieb:
> I know I've become very annoying but isn't it a way to test new releases 
> and find broken things or something of that kind and report it to 
> developers?
yes, but that also requires that you then use latest stuff build from
svn ...; after 1.9.14 there were many major changes, f.e. new kernel,
many packages updated - so things *might* have changed; therefore it is
required that you use something newer than 1.9.14 since development
advanced further ...
feel free to use a relatively new build (though not latest) from my site:
http://svwe20.itex.at/ipcop-development/

Gün.

Il 24/04/2010 12:58, Michele ha scritto:
>
>>
>> Sorry, typo.  That should read:
>> /sbin/ip route add default via 192.168.1.1 dev wan-1
>>
>>
> RTNETLINK: No such process
>
>
>> /sbin/ip route add default dev wan-1
>>
>>
> This works but the "route -n" command ouputs shows:
>
> root@andromaca:~ # route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 lan-1
> 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 wan-1
>
> Is it correct?
>
> Anyway, is there a reason why I always have to manually add default gateway?
>
> Thanks, regards.
>

Can I provide any further information?

It should be useful to add some lines of code in some script so that red 
nic:
- takes the public ip first:
- set it as the default gateway
- set modem 192.168.1.1 as the default gateway
- remove the public ip as the fedault gateway

Is it possible? How could it be done?

I know I've become very annoying but isn't it a way to test new releases 
and find broken things or something of that kind and report it to 
developers?

Thanks a lot, regards.

Giles' patch to udev has also fixed this issue for me.

Thanks Giles :)

Eric

MyStiC wrote:

> I have a Sprint U301, not other broadband ISP coverage in area. I had
> hoped IPCop 1.9.x+ would finally be able to support USB type "modems"
> but it doesn't appear to register it. There are several wireless ISP
> in the area but only via USB. Is there anyway to make this work?
> 
This particular modem not only covers 3G but also WiMax. I'm quite sure it 
can work in 3G mode though. Most 3G modems are really nothing other than 
usbserial modems as seen by the OS. The main exception is Option with their 
nozomi and hso interfaces which really work the same way at the core despite 
claims of optimized connections. One only has to read the source code to 
realize their unique interfaces are still usbserial based just named 
something else and having unique device nodes. I've had them and I see no 
evidence whatsoever of better performance over standard 3G modems that 
simply use /dev/ttyUSBX where X is the number. 

Not totally relevant to your question but here goes:

There seems to be a lack of understanding how to tune the usb link with the 
exception of the 2.6 kernel 3G driver authors. The latest 2.6 kernel 3G 
drivers do this very well and those authors know USB extremely well. In 
IPCop 1.4.18 and newer, my patch to allow an adjustable parameter to be 
applied to the usbserial driver called maxSize was employed. There are no 
2.4 kernel 3G drivers so allowing one to set the endpoint buffer size in 
usbserial via /etc/modules.conf using the maxSize parameter was necessary.
I've seen where the Vendor's Windows drivers did not take this into account 
as well and have seen dismal performance.  

A Bit of History:

Once we hit 3G in late 2005 here near Seattle, I started out with an Option 
GT which used a nozomi interface when it became available. I was able to get 
about 1.2mbs from a 1.8mbs tower link and had to compile the nozomi driver 
by hand in the IPCop build tree and hand add the device nodes. In early 2007 
I went with the Novatel XU870 and used a pcmcia caddy, this is usbserial to 
the OS. With their windows drivers and with linux, I got 700kbs. This seemed 
odd so I started digging. Rather than hardcode the parameters  into the 
usbserial driver, I went with Junxion's idea to simply have the parameter 
optional leaving the usbserial to work as it did with no parameter added. I 
tried setting the endpoint buffer at 2048 bytes, performance was better but 
big downloads produced a see saw effect indicating some congestion at the 
usb link being present but not as much. Upped it to 4096 and I started 
seeing steady 1.76mbs throughput off of the same 1.8mbs tower link. 

Note that by default usbserial's endpoint buffer size is only 64 bytes 
whereas we need 4096 bytes to really get above the usb link congestion with 
speeds over 1mbs. The patch was added to 1.4.18 later that year with Olaf's 
help in submitting it and adding the usb devices to the dialer setup page 
menu. 

Now I use a Zoom 4095 HSPA Modem with AT&T to help test IPCop 2.0 Beta and 
as a backup for DSL. My towers have been upraded to 7.2mbs and HSUPA added 
as well. Since the 3G iPhone came out, I have to compete with the droves of 
iPhone users in my area for bandwidth. At 4am I got this with the Zoom:
http://www.speedtest.net/result/658624505.png   
-- 
Dave
http://www.raqcop.com