ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #1549986, was opened at 2006-08-31 16:50
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=1549986&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: Interface Improvements (example)
Group: Next major version
Status: Open
Priority: 5
Submitted By: Robert Larsen (robotten)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ajax interface

Initial Comment:
As the number of forward rules grow, adding new ones
and displaying the list becomes very slow.
It could be nice if adding/removing/editing rules could
be done using Ajax so the list should not be
regenerated all the time.
Or maybe the list could be subdivided with a page for
each aliased interface. That could also be very helpful
for getting an overview.

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

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

On Wed, 2006-08-30 at 15:36 +0200, Franck Bourdonnec wrote:
> We will have:
> 
> 1.4 with it's GUI
> 1.5 with something like 1.4 but not really 1.4
> There is no way to transform the actual code
> with many references to 'RED' or 'GREEN'
> (eg:fixed names) to a model with independant
> interfaces names&quantity.
> 
> With this, it will be nothing but a third GUI to maintain
> because:
> 1) no way to simply forward from 1.4 to 1.5 or vice versa
> a simple improvement in GUI
> 2) we will endup writing an open a new GUI without limitation
> 
> => three GUI. Hum.

I don't agree. With the right design there shouldn't be any issue here.

Please, resurrect your interface configuration page, and we can discuss
it's merits now.

Alan.

We will have:

1.4 with it's GUI
1.5 with something like 1.4 but not really 1.4
There is no way to transform the actual code
with many references to 'RED' or 'GREEN'
(eg:fixed names) to a model with independant
interfaces names&quantity.

With this, it will be nothing but a third GUI to maintain
because:
1) no way to simply forward from 1.4 to 1.5 or vice versa
a simple improvement in GUI
2) we will endup writing an open a new GUI without limitation

=> three GUI. Hum.

On Wed, 2006-08-30 at 13:03 +0200, Gilles Espinasse wrote:
> Selon ja...@gu...:
> 
> > > I have suggested some days ago (probably lost mail) :
> > > nobody wants to waits 1.5 too much long time. Ok.
> > > So let's make ipcop 1.5 = 1.4 on k2.6 and nothing more.
> > > (the exact opposite as what I want !)
> > >
> I didn't say that we need v1.5 release in a short time.
> I say that we have to take decisions on what could be done in v1.5 and what
> could be addressed later.
> This will have great influence on when v1.5 could be available.
> Have a target in one year time look reasonable to me.
> This does not mind at all there is a deadline to release v1.5.
> As usual v1.5 should be release when it's ready. But we have to take now the
> right decisions.
> 
> > > The reason: drivers present in k2.6 and not in k2.4
> > > We can allow some variations: openswan2, new installer,
> > > hardware detection.
> > >
> > > But we have to LEAVE THE GUI in 1.4 state=>erase and copy
> > > again all 1.4 files.
> > > And we no more do major changes on this IPCop 1.4/1.5.
> > >
> No there is already difference between v1.4 and v1.5 GUI.
> I don't see a gain to loose those differences.
> This is why we all ask you (Frank) to commit changes on v1.5 in the same time
> (or before) as in v1.4. vpnmain.cgi was not updated (maybe others too).
> 
> > > In paralell, we start a NEW independant GUI (python / perl)
> > > to handle the real changes (multiple interface, brain=shorewall,
> > > ...)
> > >
> A new GUI framework adoption should be reserved for a later version.
> We already have enought work for 1.5.
> This does not mean that preliminary work to define/study what could be that new
> structure could not start now. But this need to be done by different people
> that the one actually involved or it will slow down v1.5 developpement.
> 
> I don't think that supporting multiples interfaces fully need to restart from
> the ground to rebuild an entire new GUI structure.
> > >
> > > 1) we stabilize 1.5 build process
> > > 2) reimplant ALL 1.4 GUI (thus removing all changes made by
> > > block-out which is perfect as an addon).
> > > 3) while designing future GUI, blockout stuff will naturally
> > >  integrate, with many other features.
> >
> There is no urgency that will need to remove block-out to release v1.5 that
> fast.
> 
> > I think this is wrong direction.  1.5 was to be next big leap in
> > IPCop, with modulation and more OO design in the interfaces.
> >
> > 1.4 should be in the bag.  No more large changes that take a year to
> > roll out. Installl the new Kernal.  Add new card types.   Fix bugs.
> > But no major changes.
> >
> > We can live on 1.4 for up to year, as the 1.5 works though the build
> > process, but keep 1.4 only in the fix mode.
> >
> > Jack Beglinger
> >
> 
> I agree on Jack remarks and previous Alan do.
> Our actual key points are :
> - how now set interfaces from new installer,
> - keep green / red / blue /orange asset,
> - allow multiples interfaces.

Absolutely.

I think we just need to solidify what we have that's existing in the
current 1.5 code.

I'd really like to avoid to keep upgrading the LFS files, and let's get
the GUI development underway with multiple interfaces and fixing up the
init scripts to allow for these changes.

Then, later down the road when we're getting fairly happy with the GUI
and init scripts we can look at getting the later LFS tools as long as
it doesn't burden us with a major upheaval to fixing code again.

Alan.

Selon ja...@gu...:

> > I have suggested some days ago (probably lost mail) :
> > nobody wants to waits 1.5 too much long time. Ok.
> > So let's make ipcop 1.5 =3D 1.4 on k2.6 and nothing more.
> > (the exact opposite as what I want !)
> >
I didn't say that we need v1.5 release in a short time.
I say that we have to take decisions on what could be done in v1.5 and wh=
at
could be addressed later.
This will have great influence on when v1.5 could be available.
Have a target in one year time look reasonable to me.
This does not mind at all there is a deadline to release v1.5.
As usual v1.5 should be release when it's ready. But we have to take now =
the
right decisions.

> > The reason: drivers present in k2.6 and not in k2.4
> > We can allow some variations: openswan2, new installer,
> > hardware detection.
> >
> > But we have to LEAVE THE GUI in 1.4 state=3D>erase and copy
> > again all 1.4 files.
> > And we no more do major changes on this IPCop 1.4/1.5.
> >
No there is already difference between v1.4 and v1.5 GUI.
I don't see a gain to loose those differences.
This is why we all ask you (Frank) to commit changes on v1.5 in the same =
time
(or before) as in v1.4. vpnmain.cgi was not updated (maybe others too).

> > In paralell, we start a NEW independant GUI (python / perl)
> > to handle the real changes (multiple interface, brain=3Dshorewall,
> > ...)
> >
A new GUI framework adoption should be reserved for a later version.
We already have enought work for 1.5.
This does not mean that preliminary work to define/study what could be th=
at new
structure could not start now. But this need to be done by different peop=
le
that the one actually involved or it will slow down v1.5 developpement.

I don't think that supporting multiples interfaces fully need to restart =
from
the ground to rebuild an entire new GUI structure.
> >
> > 1) we stabilize 1.5 build process
> > 2) reimplant ALL 1.4 GUI (thus removing all changes made by
> > block-out which is perfect as an addon).
> > 3) while designing future GUI, blockout stuff will naturally
> >  integrate, with many other features.
>
There is no urgency that will need to remove block-out to release v1.5 th=
at
fast.

> I think this is wrong direction.  1.5 was to be next big leap in
> IPCop, with modulation and more OO design in the interfaces.
>
> 1.4 should be in the bag.  No more large changes that take a year to
> roll out. Installl the new Kernal.  Add new card types.   Fix bugs.
> But no major changes.
>
> We can live on 1.4 for up to year, as the 1.5 works though the build
> process, but keep 1.4 only in the fix mode.
>
> Jack Beglinger
>

I agree on Jack remarks and previous Alan do.
Our actual key points are :
- how now set interfaces from new installer,
- keep green / red / blue /orange asset,
- allow multiples interfaces.

Gilles

> I have suggested some days ago (probably lost mail) :
> nobody wants to waits 1.5 too much long time. Ok.
> So let's make ipcop 1.5 = 1.4 on k2.6 and nothing more.
> (the exact opposite as what I want !)
> 
> The reason: drivers present in k2.6 and not in k2.4
> We can allow some variations: openswan2, new installer,
> hardware detection.
> 
> But we have to LEAVE THE GUI in 1.4 state=>erase and copy
> again all 1.4 files.
> And we no more do major changes on this IPCop 1.4/1.5.
> 
> In paralell, we start a NEW independant GUI (python / perl)
> to handle the real changes (multiple interface, brain=shorewall,
> ...)
> 
> 
> 1) we stabilize 1.5 build process
> 2) reimplant ALL 1.4 GUI (thus removing all changes made by
> block-out which is perfect as an addon).
> 3) while designing future GUI, blockout stuff will naturally
>  integrate, with many other features.

I think this is wrong direction.  1.5 was to be next big leap in 
IPCop, with modulation and more OO design in the interfaces.  

1.4 should be in the bag.  No more large changes that take a year to 
roll out. Installl the new Kernal.  Add new card types.   Fix bugs.  
But no major changes.  

We can live on 1.4 for up to year, as the 1.5 works though the build 
process, but keep 1.4 only in the fix mode.

Jack Beglinger

Le mardi 29 ao=FBt 2006 11:49, Alan Hourihane a =E9crit=A0:
> On Tue, 2006-08-29 at 10:44 +0100, Alan Hourihane wrote:
> > Has anyone worked on the GUI recently ?
> >
> > I fear that there is too much time being spent on the build syste=
m and
> > upgrading packages etc, than actually getting the current system =
up and
> > running.
> >
> > Can we just leave the actual build system alone now and get thing=
s up
> > and running with multiple interfaces ?
> >
> > Franck - what is the status of your webpage design for this ?
>
> And I think there are two goals for 1.5
>
> 1) 2.6 kernel
> 2) multiple interfaces, but keeping the current red, green, blue &
> orange default interfaces as well.
>
> I think we should stick with our current perl base as well. For tho=
se
> wanting to write python cgi, we already include it in the base syst=
em so
> that's not a problem.
>
> Let's not deviate outside of these goals, otherwise we'll never rel=
ease
> 1.5.
>
> Alan.
>

Hello,
I have suggested some days ago (probably lost mail) :
nobody wants to waits 1.5 too much long time. Ok.
So let's make ipcop 1.5 =3D 1.4 on k2.6 and nothing more.
(the exact opposite as what I want !)

The reason: drivers present in k2.6 and not in k2.4
We can allow some variations: openswan2, new installer,
hardware detection.

But we have to LEAVE THE GUI in 1.4 state=3D>erase and copy
again all 1.4 files.
And we no more do major changes on this IPCop 1.4/1.5.

In paralell, we start a NEW independant GUI (python / perl)
to handle the real changes (multiple interface, brain=3Dshorewall,
=2E..)


1) we stabilize 1.5 build process
2) reimplant ALL 1.4 GUI (thus removing all changes made by
block-out which is perfect as an addon).
3) while designing future GUI, blockout stuff will naturally
 integrate, with many other features.


> > Franck - what is the status of your webpage design for this ?
Dead for now, absence of reaction.


Franck

>Add some printf ,trace, to find what to do.
>Try with a real ide disk to understand how
>it works.
>
>franck

I have tried to get something to log this, but I can't get it working. I =
have tried this (and several other things that worked really bad ;-):

=3D=3D=3D 1 =3D=3D=3D
In main.c I tried to change to this, but the log is almoust empty:
#if 0
/*    snprintf(mycommand, STRING_SIZE, "%s >>%s 2>>%s", command, flog, =
flog); */
    snprintf(mycommand, STRING_SIZE, "%s >> /tmp/log1.5.txt", command);
#else
/*    snprintf(mycommand, STRING_SIZE, "%s >> /dev/tty6", command); */
    snprintf(mycommand, STRING_SIZE, "%s >> /tmp/log1.5.txt", command);
#endif
    fprintf(flog, "Running command: %s\n", command);=20
    fprintf(/tmp/log1.5.txt, "Running command: %s\n", command);=20
    return system(mycommand);
}

=3D=3D=3D 2 =3D=3D=3D
In 1.4 I could also do something similar to this:
1. Boot with CD
2. Do Alt+F3 (or was it another F-key?)
3. Manually write "/bin/iowrap /dev/tty1 /bin/ash --login -c =
/bin/installer /tmp/log1.5.txt" (or what inittab says in 1.4)
4. Installer starts again, but now logs in /tmp/log1.5.txt.
5. I mount a USB floppy, copy the file into it and can examine it on a =
normal PC.
This don't work in 1.5 (I cant mount the USB floppy or USB memory as I =
can in 1.4)

=3D=3D=3D 3 =3D=3D=3D=20
And if I get it working. How can I get the log from the laptop? In 1.4 I =
can mount USB memory and/or USB floppy, but in 1.5 I can't mount them =
:-(

=3D=3D=3D 4 =3D=3D=3D
Is it possible for somebody to send me a log of the commands that run on =
1.5 from start of installation to the end? Then I can boot with CD, do =
Alt+Fx trick, run all commands manually and that way see where it stops =
working (and maybe also see some nice error info).

>That's you that upgrade parted to 1.7.0.
>What is not better before ?
>
>Your only message for the update is 'Update.'
>
>As a notice, parted-1.7.1 was out only some days after parted-1.7.0.
>This is a clue that probably something was broken in 1.7.0.
>
>Looking at a diff -Nru (hudge 494 kB in less than two weeks) show in =
NEWS
>file
>+1.7.1
>+=3D=3D=3D=3D=3D
>+libparted:
>+* bug fixes related to linking, HFS, ext2, the Mac disk label
>+
>+parted:
>+* signal handling bug fix
>+
>+
> 1.7.0
>
>Gilles

Is this something I should try to update?

On 29 Aug 2006, at 10:44, Gilles Espinasse wrote:

> My idea of the todo was more to use the todo as a detailled task  
> list of what
> has to be done on futur versions than on v1.4.
>
> I agree we could/should to have one for v1.4 too.
>
> We have to focus development on futur versions and sometime  
> backport a few
> things because time on next version could be somewhat long.
>
> I have slightly changed your initial presentation to give more  
> details on next
> v1.4 releases.
>
> Gilles

OK, my bad.

Thanks for tidying it up.

Eric

>> I'm interested with some $$ because I spend much time (no job since 3
years)
>> for IPCop ;-)
>


I hope no-one thought I was trying to push Franck out with regard to this
job I'm not in a position to do the full job, Franck is much better able
to do this than me, I'm just offering to help/test.

Andre

> On Tue, 29 Aug 2006, Andre Newman wrote:
>
>> Actually we have a couple of ADSL's I could test with, I'll see if the=
re
>> is a bit of cash to buy a couple of Sangoma ADSL cards.
>
> Where are you based? Perhaps I can loan you a couple of S518 ADSL cards
> for development.

Biggin Hill alongside the Airport, south of London, just inside the M25
carpark, come on down & I'll give you the tour. We have an office in
central London too if that's easier, no tours there though, not that
there's anything to see there.

I'm a bit limited in that I can only steal use of the backup ADSL every
other week for testing, so might get better value loaning those cards to
someone else.

Regards

Andre

On Tue, 29 Aug 2006, Andre Newman wrote:

> Actually we have a couple of ADSL's I could test with, I'll see if ther=
e
> is a bit of cash to buy a couple of Sangoma ADSL cards.

Where are you based? Perhaps I can loan you a couple of S518 ADSL cards=20
for development.

> btw Hi Jason, I sent you a new customer last week, one of many of cours=
e...

Thanks. I'm always happy to welcome new customers ;)

Jason
--=20
UKFSN.ORG			Finance Free Software while you surf the 'net
http://www.ukfsn.org/		  up to 8Mb ADSL Broadband from just =A314.98
http://www.linuxadsl.co.uk/		ADSL routers from just =A321.98

>> I've just completed a project to build IPCop onto Cobalt 3i. It is up
>> and running on our systems.
>>
>> If you want to try out the ISO, please let me know and I'll point you
>> at the url. I have limited bandwidth at the moment, but can make
>> arrangements if the masses need it pronto.


I've got an old 3i lurking here, I don't think I can get the Boss to
donate it but I could probably help with some testing.

Regards

Andre

> Adding support of another bonded interface is far less simple.
> It would need to modify ip-up, ip-down to support more than one interfa=
ce.
> This will break my somewhat ugly rc.connectioncheck wich is only a hack
> but
> was more efficient than the actual ppp-2.4.2 version we actually use to
> reconnect.

Hi, I'm using the wanpipe drivers with leased line cards (same software),
if I understand it correctly it looks to me like the wanpipe software wil=
l
hide a bonded connection from IPCop so I don't think any extra work will
be needed.

When you bring up a wanpipe interface there is a wp1 interface which seem=
s
to be the physical interface and a wp1ppp virtual interface which is the
one you actually send traffic to. If you use bonding (configured within
wanpipe) you get wp1 & wp2 but still only wp1ppp.


I'm hoping to test a 1.4.12 compile on a spare FW with a Sangoma X21 card
this week, if there's anything I can try out let me know, I know the
Leased line cards are different to ADSL ones but the software seems the
same. I think my X21 card has two interfaces so I can try the bonding
thing.

BTW Sangoma are pretty helpful when it comes to supporting OSS, they adde=
d
a few tweaks to their compile scripts for IPCop when I asked.


>
> Then we would need to modify firewall rules application and rc.red star=
t
> script.

I've been thinking that Leased line support would be better in with
ADSL/ISDN/Modem than the pretend Ethernet hack I'm using at the moment,
I'm happy to help in getting this all sorted out to everyone's benefit.
Work pays me to do this stuff so I'm not after a share of the bounty.

Actually we have a couple of ADSL's I could test with, I'll see if there
is a bit of cash to buy a couple of Sangoma ADSL cards.

btw Hi Jason, I sent you a new customer last week, one of many of course.=
..


Regards

Andre

On Tue, 2006-08-29 at 10:44 +0100, Alan Hourihane wrote:
> Has anyone worked on the GUI recently ?
> 
> I fear that there is too much time being spent on the build system and
> upgrading packages etc, than actually getting the current system up and
> running.
> 
> Can we just leave the actual build system alone now and get things up
> and running with multiple interfaces ?
> 
> Franck - what is the status of your webpage design for this ?

And I think there are two goals for 1.5

1) 2.6 kernel
2) multiple interfaces, but keeping the current red, green, blue &
orange default interfaces as well.

I think we should stick with our current perl base as well. For those
wanting to write python cgi, we already include it in the base system so
that's not a problem.

Let's not deviate outside of these goals, otherwise we'll never release
1.5.

Alan.

Has anyone worked on the GUI recently ?

I fear that there is too much time being spent on the build system and
upgrading packages etc, than actually getting the current system up and
running.

Can we just leave the actual build system alone now and get things up
and running with multiple interfaces ?

Franck - what is the status of your webpage design for this ?

Alan.

Selon Eric Oberlander <er...@ob...>:

> On 25 Aug 2006, at 22:09, Gilles Espinasse wrote:
>
> > I talk with Eric Oberlander of the interest to write a simple Todo
> > file.
> > This could be written on doc directory of the CVS or on the wiki.
> >
> > This is intended to collect what should be done in the near or far
> > futur.
> > It could allow a better coordination between developpers (not
> > having one
> > that change in one direction when another intend to change another
> > way a bit
> > later).
>
> snip..
>
> To get the ball rolling I've created a topic on the phpWiki, linked
> from the Road Map page:
> http://www.ipcop.org/modules.php?
> op=3Dmodload&name=3DphpWiki&file=3Dindex&pagename=3DIPCop14ToDo
>
> If you don't have the necessary editing rights, please contact the
> Site Admins to obtain them, or post them to me.
>
> Eric
>
My idea of the todo was more to use the todo as a detailled task list of =
what
has to be done on futur versions than on v1.4.

I agree we could/should to have one for v1.4 too.

We have to focus development on futur versions and sometime backport a fe=
w
things because time on next version could be somewhat long.

I have slightly changed your initial presentation to give more details on=
 next
v1.4 releases.

Gilles

Eric,

Can you get the language folks to fix the ja_JA language database.

Here's the errors....

/usr/src/langs/ja_JA/ipcop.po:70: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:70:11: parse error
/usr/src/langs/ja_JA/ipcop.po:71: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:123: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:123:2: parse error
/usr/src/langs/ja_JA/ipcop.po:124: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:674: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:674:6: parse error
/usr/src/langs/ja_JA/ipcop.po:675: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:877: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:877:2: parse error
/usr/src/langs/ja_JA/ipcop.po:878: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:1816: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:1816:2: parse error
/usr/src/langs/ja_JA/ipcop.po:1817: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:1867: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:1867:2: parse error
/usr/src/langs/ja_JA/ipcop.po:1868: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:1876: end-of-line within string
/usr/src/langs/ja_JA/ipcop.po:1876:2: parse error
msgfmt: too many errors, aborting

Alan.

On Tue, 29 Aug 2006, Franck Bourdonnec wrote:

> While looking/inserting the sangoma (wanpipe driver) I saw a certain nu=
mbers
> of options in configfiles.
> It is not very much complicated to add GUI support to manage .conf, a l=
ittle=20
> bit more complicated in actual rc.* scripts.

I suspect the main challenge will be to provide a relatively easy way for=
=20
users to configure the devices rather than anything else. To setup for a=20
single Sangoma card should be trivial however to configure for 2 or more=20
you have to identify the PCI card (usually by reading the lspci output) b=
y=20
it's PCI Slot and PCI Bus numbers which are then used in the=20
/etc/wanpipe/wanpipe[0,1,2,3,...] files.

Once that is done the rest of the device configuration file is just about=
=20
setting the standard ADSL paramters (Encapsulation, VCI, VPI).

The operation mode should be set to TTY.

The device files needed are /dev/ttyWP# on major 240, minor 0-32 as per=20
device requirements.

Usually people use the Sangoma supplied wancfg utility for this but it's=20
not necessary.

Once the cards have been configured they are activated using the wanstart=
=20
utility.

Then it's absolutely standard ppp configuration as it is for ISDN.

> I'm interested with some $$ because I spend much time (no job since 3 y=
ears)
> for IPCop ;-)

The cash offer is for the Sangoma support rather than the BeWAN as the=20
latter will require work on the part of Bewan before it can happen and=20
they have not indicated whether they are interested.

> http://www.ipcop.org/modules.php?op=3Dmodload&name=3DphpWiki&file=3Dind=
ex&pagename=3DIPCopDonations

I was aware of that hence my email.

Jason
--=20
UKFSN.ORG			Finance Free Software while you surf the 'net
http://www.ukfsn.org/		  up to 8Mb ADSL Broadband from just =A314.98
http://www.linuxadsl.co.uk/		ADSL routers from just =A321.98

On 25 Aug 2006, at 22:09, Gilles Espinasse wrote:

> I talk with Eric Oberlander of the interest to write a simple Todo  
> file.
> This could be written on doc directory of the CVS or on the wiki.
>
> This is intended to collect what should be done in the near or far  
> futur.
> It could allow a better coordination between developpers (not  
> having one
> that change in one direction when another intend to change another  
> way a bit
> later).

snip..

To get the ball rolling I've created a topic on the phpWiki, linked  
from the Road Map page:
http://www.ipcop.org/modules.php? 
op=modload&name=phpWiki&file=index&pagename=IPCop14ToDo

If you don't have the necessary editing rights, please contact the  
Site Admins to obtain them, or post them to me.

Eric

OK, here it is:

  http://sourceforge.net/tracker/index.php?func=detail&aid=1548267&group_id=40604&atid=428519

On 8/28/06, Gilles Espinasse <g....@fr...> wrote:
>
> ----- Original Message -----
> From: "Paul Charles Leddy" <pc...@gm...>
> To: <ipc...@li...>
> Sent: Monday, August 28, 2006 7:59 PM
> Subject: [IPCop-devel] IPCop on Colbalt Raq 3i
>
>
> > I've just completed a project to build IPCop onto Cobalt 3i. It is up
> > and running on our systems.
> >
> > If you want to try out the ISO, please let me know and I'll point you
> > at the url. I have limited bandwidth at the moment, but can make
> > arrangements if the masses need it pronto.
> >
> > A major thanks to Lorant Leopold whose post gave me initial assurance,
> > and whose correspondence saved me days. And Jeff Walter for his Holy
> > Grail website.
> >
> > The diff is very small. I can send that along too by request. Will
> > post eventually online, but wanted to get the word out for now via
> > this little post.
> >
> Thank for your input
> If you want to send a patch, the best way is to post a RFE and attach
> patches
>
> I can't compile actually on this architecture.
> This will only change if someone could offer me one machine.
>
> Gilles Espinasse
>
>


-- 

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

I forgot about the RFE feature. I have now posted one. Located at 1548348.

Feature Requests item #1548348, was opened at 2006-08-29 08:27
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=1548348&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
Submitted By: Niklas Persson (blinkiz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Dynamic DNS provider Namecheap

Initial Comment:
I would like to see support for the Dynamic DNS
provider Namecheap.com

The string namecheap are using is:
https://dynamicdns.park-your-domain.com/update?host=host_name&domain=domain.com&password=domain_password[&ip=your_ip]
Port 80, http://, does also work.
for example, in myip.johnsmith.com, myip is the
host_name, johnsmith.com is the domain. If you don't
specify any IP, the IP from which you are accessing the
URL will be set for the domain.

I have a more details in the thread at
http://www.ipcops.com/index.php?name=PNphpBB2&file=viewtopic&t=7915


Can the dev team please give support for this Dynamic
DNS provider? 

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

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

Feature Requests item #1548267, was opened at 2006-08-29 00:39
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=1548267&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
Submitted By: Paul C Leddy (holon67)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPCop on Cobalt Raq 3i

Initial Comment:
Here is software patch to get IPCop to boot on a
Cobalt's Raq 3i (other versions untested).

Additionally, for a successful boot, this ROM upgrade
is required, just one reason being ext3 support:

  Version <= 2.10.3

See: http://gentoo.404ster.com/texts.php?action=view&id=5

Patches may need cleanup.

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

Patches follow new e100 patch file not in cvs:

Location: src/patches/linux-2.4.26-e100.patch

----START e100 patch file----

--- drivers/net/e100/e100_main.c.orig	2006-08-21
19:18:29.000000000 -0700
+++ drivers/net/e100/e100_main.c	2006-08-21
19:20:56.000000000 -0700
@@ -673,7 +673,8 @@
 	/* Check if checksum is valid */
 	cal_checksum = e100_eeprom_calculate_chksum(bdp);
 	read_checksum = e100_eeprom_read(bdp,
(bdp->eeprom_size - 1));
-	if (cal_checksum != read_checksum) {
+//	if (cal_checksum != read_checksum) {
+	if (0) {
                 printk(KERN_ERR "e100: Corrupted
EEPROM on instance #%d\n",
 		       e100nics);
                 rc = -ENODEV;

----END e100 patch file----

-----Patches----

? diff.txt
? src/patches/linux-2.4.26-e100.patch
Index: config/etc/inittab
===================================================================
RCS file: /cvsroot/ipcop/ipcop/config/etc/inittab,v
retrieving revision 1.6.2.1
diff -u -r1.6.2.1 inittab
--- config/etc/inittab	24 Jan 2006 15:25:35 -0000	1.6.2.1
+++ config/etc/inittab	29 Aug 2006 00:18:48 -0000
@@ -12,12 +12,17 @@
 ca::ctrlaltdel:/sbin/shutdown -r now
 
 # Run gettys in standard runlevels
-1:2345:respawn:/sbin/mingetty tty1
-2:2345:respawn:/sbin/mingetty tty2
-3:2345:respawn:/sbin/mingetty tty3
-4:2345:respawn:/sbin/mingetty tty4
-5:2345:respawn:/sbin/mingetty tty5
-6:2345:respawn:/sbin/mingetty tty6
+#1:2345:respawn:/sbin/mingetty tty1
+#2:2345:respawn:/sbin/mingetty tty2
+#3:2345:respawn:/sbin/mingetty tty3
+#4:2345:respawn:/sbin/mingetty tty4
+#5:2345:respawn:/sbin/mingetty tty5
+#6:2345:respawn:/sbin/mingetty tty6
+
+s0:12345:respawn:/sbin/agetty ttyS0 115200 vt100
+s1:12345:wait:/sbin/agetty ttyS1 115200 vt100
 
 # Going single user mode for maintenance
 xx:S1:respawn:/bin/bash
+
Index: config/etc/securetty
===================================================================
RCS file: /cvsroot/ipcop/ipcop/config/etc/securetty,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 securetty
--- config/etc/securetty	27 Nov 2001 08:09:52 -0000	1.1.1.1
+++ config/etc/securetty	29 Aug 2006 00:18:48 -0000
@@ -20,3 +20,5 @@
 ttypd
 ttype
 ttypf
+ttyS0
+ttyS1
Index: config/grub/grub.conf
===================================================================
RCS file: /cvsroot/ipcop/ipcop/config/grub/grub.conf,v
retrieving revision 1.5.2.5
diff -u -r1.5.2.5 grub.conf
--- config/grub/grub.conf	27 Aug 2004 09:59:56 -0000
1.5.2.5
+++ config/grub/grub.conf	29 Aug 2006 00:18:48 -0000
@@ -1,8 +1,12 @@
-timeout 5
-default saved
-foreground = 16064e
-background = ffffff
-splashimage (hd0,0)/grub/ipcop.xpm.gz
+#timeout 5
+default=0
+#foreground = 16064e
+#background = ffffff
+#splashimage (hd0,0)/grub/ipcop.xpm.gz
+title IPCopD
+  root (hd0,0)
+  kernel /vmlinux.bz2 root=ROOT panic=10 acpi=off ro
+#  savedefault
 title IPCop
   root (hd0,0)
   kernel /vmlinuz root=ROOT panic=10 acpi=off ro
@@ -19,3 +23,4 @@
   root (hd0,0)
   kernel /vmlinuz-smp root=ROOT panic=10 acpi=ht ro
   savedefault
+
Index: lfs/linux
===================================================================
RCS file: /cvsroot/ipcop/ipcop/lfs/linux,v
retrieving revision 1.42.2.66
diff -u -r1.42.2.66 linux
--- lfs/linux	15 Jul 2006 23:51:29 -0000	1.42.2.66
+++ lfs/linux	29 Aug 2006 00:18:52 -0000
@@ -201,6 +201,9 @@
 	# Fix libata-core.c
 	# cd $(DIR_APP) && patch -Np0 <
$(DIR_SRC)/src/patches/linux-2.4.26-scsi.patch
 
+	# Fix e100_main.c to load without checksum
+	cd $(DIR_APP) && patch --verbose -Np0 <
$(DIR_SRC)/src/patches/linux-2.4.26-e100.patch
+
 	# frandom patch
 	cd $(DIR_APP) && patch -Np1 <
$(DIR_SRC)/src/patches/linux-2.4.27-frandom-2.patch
 
@@ -236,6 +239,10 @@
 	cd $(DIR_APP) && make CC="$(KGCC)" dep
 	cd $(DIR_APP) && make CC="$(KGCC)" clean
 	if [ "$(MACHINE)" = "i386" -a "$(SMP)" = "" ]; then \
+		cd $(DIR_APP) && make -j 3 CC="$(KGCC)" vmlinux; \
+		cd $(DIR_APP) && bzip2 vmlinux; \
+		cd $(DIR_APP) && cp vmlinux.bz2
/boot/vmlinux-$(VER).bz2; \
+		ln -sf vmlinux-$(VER).bz2 /boot/vmlinux.bz2; \
 		cd $(DIR_APP) && make -j 3 CC="$(KGCC)" bzImage; \
 		cd $(DIR_APP) && cp arch/$(MACHINE)/boot/bzImage
/boot/vmlinuz-$(VER); \
 		cd $(DIR_APP) && cp System.map
/boot/System.map-$(VER); \
Index: src/ROOTFILES.i386
===================================================================
RCS file: /cvsroot/ipcop/ipcop/src/Attic/ROOTFILES.i386,v
retrieving revision 1.23.2.177
diff -u -r1.23.2.177 ROOTFILES.i386
--- src/ROOTFILES.i386	11 Aug 2006 06:13:26 -0000
1.23.2.177
+++ src/ROOTFILES.i386	29 Aug 2006 00:19:01 -0000
@@ -10,8 +10,10 @@
 ## linux-2.4.31-ipcop
 ##
 boot/vmlinuz-2.4.31
+boot/vmlinux-2.4.31.bz2
 boot/System.map-2.4.31
 boot/vmlinuz
+boot/vmlinux.bz2
 boot/System.map
 #lib/modules/2.4.31
 lib/modules/2.4.31/kernel
@@ -16505,7 +16507,7 @@
 bin/mount
 bin/umount
 etc/fdprm
-#sbin/agetty
+sbin/agetty
 sbin/blockdev
 sbin/cfdisk
 sbin/ctrlaltdel
Index: src/rc.d/rc.sysinit
===================================================================
RCS file: /cvsroot/ipcop/ipcop/src/rc.d/Attic/rc.sysinit,v
retrieving revision 1.18.2.39
diff -u -r1.18.2.39 rc.sysinit
--- src/rc.d/rc.sysinit	26 Jul 2006 19:25:50 -0000
1.18.2.39
+++ src/rc.d/rc.sysinit	29 Aug 2006 00:19:02 -0000
@@ -154,9 +154,9 @@
 
 echo "Setting consolefonts"
 eval $(/usr/local/bin/readhash CONFIG_ROOT/main/settings)
-for i in 2 3 4 5 6; do
-	> /dev/tty$i
-done
+#for i in 2 3 4 5 6; do
+#	> /dev/tty$i
+#done
 if [ "$LANGUAGE" = "el" ]; then
 	/usr/bin/unicode_start iso07u-16
 elif [ "$LANGUAGE" = "pt" -o "$LANGUAGE" = "bz" ]; then


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

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

Hello Addon developpers and others,


As the author of an addon myself, I can see some annoying problems
when it is time to mix the addon into IPCop (install).

A problem is locate the correct place to insert a piece of code into
an existing source. An action button into a GUI screen for example.

diff can work well enought but when another addon also tweaked the file or
the source is updated,... hum...

I suggest a simple thing to help:
Place some TAGs where/when required by you.

#TAG:xyz

and you just issue a s/TAG:xyz/TAG:xyz \n yourtweak in the file/

Franck