ipcop-devel Mailing List for IPCop Firewall

Regarding bandwidth control, Im sure this comes under the section,

'Prioritizing empty TCP ACKs with pf and ALTQ'



Yes this applys to OpenBSD however; I think if this could be implemented via
IPTABLES or whatever then most people will in reality get extra bandwidth
becuase of this. Instead of say limiting upload at 10kb/s on a 30kb/s line
or somthing so that the ping/downloads will be manageable/speedy.

If this can already be done via QoS in the Linux kernel then mabie someone
could investigate it?

Im just throwing ideas around really - I saw this on www.deadly.org and
thought if this could be applyed to IPCop in the future or somthing then it
would be a real bonus. I mean just look at the results and stats for
yourself!

If this is what you people are talking about then just dis-reguard this
post. Somtimes I dont even know what I'm on abut somtimes!

Thought I'd let you know about it anyhow.


James.

Hi,

>>I have just modified the 1.3 code (not in cvs,  need to test
>>compilation) to build a custom tc binary from the iproute2 code and the
>>htb test.  I also enabled CONFIG_NETFILTER_DEV.
> 
> Let me know how you go .. when it makes it to CVS I'll do a build and run a
> test machine at work.

I just committed the code to cvs.

Kind regards,

Mark
-- 
***************************************************************
* |\    /|      |  /|  /       Mark Wormgoor                  *
* | \  / |      | / | /        mailto:ma...@wo...       *
* |  \/  |ark   |/  |/ormgoor  http://www.wormgoor.com/mark/  *
***************************************************************

On Mon, 31 Mar 2003 20:34:21 +0200, 
"Mark Wormgoor" <ma...@wo...> wrote in message 
<005401c2f7b4$2615ebe0$0400a8c0@markxp>:

> The second step is to support multiple green/orange/red interfaces. 
> And that will be a lot harder.
>

..yet another reason to toss the smoothwall code and chuck in the 
shorewall and webmin bits in 1.4 tree;  simply a case of adding 
nics and then call it "blue 3" or whatever.  

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Can you give me any idea(s) on how you plan on going about this? I'm working
on multiple NICs and multiple IP addresses on a single NIC right now. I'm
only modifying shell scripts, (I can't program in C) but if I can aim in the
general direction, I may make something that you could use when you start
looking at it. (then again, I may not, but what the hey) ;)

I've read and studied all of the netfilter howtos, so I'm pretty comfortable
with iptables and I'm also using the ip command exclusively instead of the
thin wrappers: ifconfig and route.

Anyone who wants to look at what I've done is welcome to it. I'm nowhere
near done yet, but it is something my company needs, so I'm able to put some
quality time into it.

Thanks,
David Ruggles

CCNA MCSE (NT) CNA A+
Network Engineer, Safe Data, Inc
910-285-7200    da...@sa...
0100011101101111011001000110110001101111011101100110010101110011011110010110
111101110101
----- Original Message -----
From: "Mark Wormgoor" <ma...@wo...>
To: <ipc...@li...>
Sent: Monday, March 31, 2003 1:34 PM
Subject: Re: [IPCop-devel] multiple green nets


> Hi,
>
> > I had been looking at this myself as another firewall distro out there
has
> > an alias page for green.
> > On close inspection of the firewall rules, it should be as simple as
using
> > ifconfig to add an alias to the green.
> > The tricky part is portforwarding, external access, dns, basically any
> > firewall rules that specify an address instead of an interface. Which as
> > noted was only a few.
> > I have not had time to play with this, but it is something that I am
> > interested in as well. Just examine how the red interface is aliased for
> an
> > example of how to use ifconfig to set up aliases on the green.
>
> I don't really think you want aliases on green though.  There are two ways
> to go with this, and we want to support both in the future.  The easy
first
> step is to support static routes.  That way we'll support users with
larger
> networks.
> The second step is to support multiple green/orange/red interfaces.  And
> that will be a lot harder.
>
> Kind regards,
>
> Mark
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

Hi,

> There are no major changes since beta2, only small fixes.  This release
> is mainly for the translators to test their works.  As far as I know,
> there are no more interface glitches.

It was just pointed out to me by Darren that the glitches are still there
for the setup user after a config restore, not for new installs.  The reason
is that /etc/passwd is restored with an old shell for setup.  The upgrade
process will take care of this in the final build.  For now, change the
setup user line in /etc/passwd from:
setup:x:0:0:root:/:/usr/local/sbin/setup

to:
setup:x:0:0:root:/:/bin/bash -c /usr/local/sbin/setup

Kind regards,

Mark

On Sun, 30 Mar 2003 13:44:40 -0800, phil <ph...@os...> wrote:

>Greetings !
>
>I can not confirm that modem not working problem.  I just installed
>ipcop 1.3beta3 and this message was written with it. There for I
>suggest the guy try changing the com port.
>
>(Sorry I didn't quote the original message I am on another box.)

I went back and tried again, and the second
installation worked ! no idea why it was different
2nd time

Mark, please disregard the false alarm

best regards
Dave Morgan

--=20
http://www.eclipse.co.uk/morgad/index.html      gpg:0x64B5E037=20
fingerprint:AD3B 81F6 63A3 C921 D5AA  D1BD 83D0 9548 64B5 E037
UKRA#1243
from address killfiled. use reply-to address for replies !

Hi,

> I had been looking at this myself as another firewall distro out there has
> an alias page for green.
> On close inspection of the firewall rules, it should be as simple as using
> ifconfig to add an alias to the green.
> The tricky part is portforwarding, external access, dns, basically any
> firewall rules that specify an address instead of an interface. Which as
> noted was only a few.
> I have not had time to play with this, but it is something that I am
> interested in as well. Just examine how the red interface is aliased for
an
> example of how to use ifconfig to set up aliases on the green.

I don't really think you want aliases on green though.  There are two ways
to go with this, and we want to support both in the future.  The easy first
step is to support static routes.  That way we'll support users with larger
networks.
The second step is to support multiple green/orange/red interfaces.  And
that will be a lot harder.

Kind regards,

Mark

FMJLB ?
FMJLD ?

> -----Original Message-----
> From: ipc...@li... 
> [mailto:ipc...@li...] On Behalf Of 
> Arnt Karlsen
> Sent: Monday, March 31, 2003 9:37 AM
> To: ipc...@li...
> Subject: Re: [IPCop-devel] v1.3b3 - bandwidth control
> 
> 
> On Mon, 31 Mar 2003 23:55:06 +1000, 
> "David Kilpatrick" <da...@da...> wrote in message 
> <000e01c2f78d$23bacf90$640...@rg...>:
> 
> > The traffic graphs faied to work because the system was 
> installed on a 
> > machine that thought it was April 2. Hence when I rolled 
> the date back 
> > to March 31 (using the ntpdate feature) .. ipac-2-mrtg started 
> > complaining the log files were from the future. This might 
> be one of 
> > the caevets of using the ntpdate function perhaps.
> 
> ..for ideas: 'touch --help' on ipcop, 'info touch' on a FMJLB.
> 
> ..FWIW, ipcop is _not_ a FMJLD, and an ipcop box is no FMJLB.  ;-)
> 
> -- 
> ..med vennlig hilsen = with Kind Regards from Arnt... ;-) 
> ...with a number of polar bear hunters in his ancestry...
>   Scenarios always come in sets of three: 
>   best case, worst case, and just in case.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your 
> dedicated server 
> http://click.atdmt.com/AFF/go/sdnxxaff00300020> aff/direct/01/
> 
> 
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li... 
> https://lists.sourceforge.net/lists/listinfo/i> pcop-devel
> 

----- Original Message -----
From: "Casey Boone" <ca...@yo...>
To: <ipc...@li...>
Sent: Monday, March 31, 2003 7:40 AM
Subject: RE: [IPCop-devel] Announcement: IPCop v1.3 beta3


> > Actually I like this idea of a chain in there that can be
> > used for users that want to add rules to the tables, is it
> > possible to take it one step further and have rc.firewall.up
> > include another file called "custom" as an example - that way
> > people can be directed to enter their changes into the
> > "custom" file and should be pretty safe in the knowledge that
> > their chain is in the correct place in iptables. And that if
> > something goes wrong, they just need to remove the include or
> > clear the "custom" file.
> >
> > Darren
>
> This would be a godsend
>
> A supported custom startup script file that gets backed up with
> everything else when you issue a backup.  I have had to add custom
> routing to a few ipcop boxes, and having a central place for this in the
> web management would be quite nice.
>
I didn't say in the webbased gui as that cannot be added to 1.3 at this
point, just a file that everyone knows exists, and where you can add rules
to the iptables.

It is the longterm goal of the dev team to work towards a full fledged
iptables editor eventually, so you will get what you want at some point in
the web gui.

Darren

----- Original Message -----
From: "Mark Olliver" <mp...@th...>
To: <ipc...@li...>
Sent: Monday, March 31, 2003 4:35 AM
Subject: [IPCop-devel] multiple green nets

>Hi
>
>I know this will be hard, but I would like to implement aliases on the
>green network, (shades of green).
>
>I think a lot more people would start using ipcop if this could be
>implemented.
>
>I know of serveral companies who implement multiple lans, which go
>through one firewall, this firewall does both internal and external
>firewalling, where a green net to one would be red to the next however,
>not the main red net.
>
>Any ideas on how to start this?

I had been looking at this myself as another firewall distro out there has
an alias page for green.
On close inspection of the firewall rules, it should be as simple as using
ifconfig to add an alias to the green.
The tricky part is portforwarding, external access, dns, basically any
firewall rules that specify an address instead of an interface. Which as
noted was only a few.
I have not had time to play with this, but it is something that I am
interested in as well. Just examine how the red interface is aliased for an
example of how to use ifconfig to set up aliases on the green.

Darren

On Mon, 31 Mar 2003 12:59:09 +0100, 
Eric Oberlander <er...@ob...> wrote in message 
<BAADEBA4.38B7%er...@ob...>:

> on 31/3/03 12:41 pm, Dave Roberts at da...@cz... wrote:
> 
> >> What does everyone think?
> > 
> > I say leave it out of 1.3 stable.  You can then look at releasing as
> > a patch or 1.3.1 in a few months after it has been tested.
> > 

..you guys have branched off 1.3 in cvs yet? 
(Found I need to redo my co script.)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Hi

Is there any reason why that by default ,( and web based methods) no
firewalling is done from the local interface.

I feel it is quite common to see this kind of firewalling done, and can
contribute to being a good net-citizen. For example we dont want really
want our users having the ablilty to do certain things, also it can save
us bandwith, if we stop it here then we are not fetching it in the first
place.

any ideas? it should be fairly east to implement with only a small
change to the UI. (This could be an advanced mode, so people can either
choose standard ie allow all out or advanced allow some out?)

what do people think

Mark

On Mon, 31 Mar 2003 23:55:06 +1000, 
"David Kilpatrick" <da...@da...> wrote in message 
<000e01c2f78d$23bacf90$640...@rg...>:

> The traffic graphs faied to work because the system was installed on a
> machine that thought it was April 2. Hence when I rolled the date back
> to March 31 (using the ntpdate feature) .. ipac-2-mrtg started
> complaining the log files were from the future. This might be one of
> the caevets of using the ntpdate function perhaps.

..for ideas: 'touch --help' on ipcop, 'info touch' on a FMJLB.

..FWIW, ipcop is _not_ a FMJLD, and an ipcop box is no FMJLB.  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

> Actually I like this idea of a chain in there that can be 
> used for users that want to add rules to the tables, is it 
> possible to take it one step further and have rc.firewall.up 
> include another file called "custom" as an example - that way 
> people can be directed to enter their changes into the 
> "custom" file and should be pretty safe in the knowledge that 
> their chain is in the correct place in iptables. And that if 
> something goes wrong, they just need to remove the include or 
> clear the "custom" file.
> 
> Darren

This would be a godsend

A supported custom startup script file that gets backed up with
everything else when you issue a backup.  I have had to add custom
routing to a few ipcop boxes, and having a central place for this in the
web management would be quite nice.

Casey

On Mon, 31 Mar 2003 22:55:49 +1000, 
"David Kilpatrick" <da...@da...> wrote in message 
<004001c2f784$dabae3a0$640...@rg...>:
> ----- Original Message -----
> From: "Ufuk Altinkaynak" <ufu...@wi...>
> To: "David Kilpatrick" <da...@da...>;
> <ipc...@li...>
> Sent: Monday, March 31, 2003 7:52 PM
> Subject: Re: [IPCop-devel] v1.3b3 - bandwidth control
> >
> > Can you make the nessary files availble for download ??
> > As i am also working on it (the problem is, that my time is soooo

..ugh, another one in the club.  

> > limited), i would start to write the web-frontend, based on your
> > work.

..yess!  ;-)

> > BTW here are my used links for Qos
> > http://users.belgacom.net/staf/qos/links.html
> > http://lartc.org/wondershaper/

..good setup choice for the average ipcop user.

> > Under http://www.docum.org/ i found realy interesting and for me
> > most usefull information, i also aksed the developer last year to
> > use some of his code for a ipcop Project, an he said yes.
> > under http://home.docum.org/qos/ runs a impressive Web Gui Demo
> >
> > But for the beginning a simple Web-Frontend would be enough or ???

..yes, can be written from scratch or dug out of webmin(.com)'s
shorewall(.net) module, there's also a 3'rd party TOS module.

..should come up with either shorewall or wondershaper defaults on
fresh installs, say, as the "basic" option.

> Hi Ufuk ..
> 
> I took a quick look at those config page examples you pointed out, and
> I feel they might be a little over the top. 

..ok, we just call this the "advanced customizer" option and throw 
it in, too, and with a "newbie, lay off" warning, could make ipcop 
useful for isp carrier grade service too.  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

> The current machine I am testing at work has been running very well since
I
> put it in 12 hours ago (though the traffic and proxy graphs aren't
working.
> It's proably just my build)

The traffic graphs faied to work because the system was installed on a
machine that thought it was April 2. Hence when I rolled the date back to
March 31 (using the ntpdate feature) .. ipac-2-mrtg started complaining the
log files were from the future. This might be one of the caevets of using
the ntpdate function perhaps.

Still working on findout why the proxy graphs don't work (though I suspect
it may be the same reason)
--
David Kilpatrick
da...@da...

Hi David

David Kilpatrick wrote:
> Hi Ufuk ..
>
> I took a quick look at those config page examples you pointed out,
> and I feel they might be a little over the top. But let me explain
> why.

Well i agree with you.
I just wanted to say, that the provided informations on the posted sites,
where usefull for me to understand Qos

>
> Essentially I felt the web config page would give you the ability to
> define uplink and downlink speeds (ie 128/512 for ADSL) .. as well as
> protocols and/or hosts to add to the high priority queue. Perhaps as
> an added measure, provide the ability to change the ratio of
> bandwidth to be allocated between high and low priority queues etc..

100% agree.
I also think that this is what most ipcop users want.

What you wrote is nearly the same, what i wanted to do.
As i wrote, i will try to finish this weekend a simple Web-Gui, what do you
think are the minimum required  functions ??

Regards
Ufuk Altinkaynak

> > RE: kernel update .. I had to enable CONFIG_NETFILTER_DEV.
> > Also, the version of tc supplied with v1.3b3 is not compatible with the
> > latest version of HTB.
> > Martin Devera has a binary available here:
> > http://luxik.cdi.cz/~devik/qos/htb/
> > That is required for HTB to work.
>
> I have just modified the 1.3 code (not in cvs,  need to test
> compilation) to build a custom tc binary from the iproute2 code and the
> htb test.  I also enabled CONFIG_NETFILTER_DEV.
>

Let me know how you go .. when it makes it to CVS I'll do a build and run a
test machine at work.
The current machine I am testing at work has been running very well since I
put it in 12 hours ago (though the traffic and proxy graphs aren't working.
It's proably just my build)

> Even if we get it done, we risk introducing bugs into 1.3 at the last
> moment.
> What does everyone think?

I am in 2 minds over this ... my testing so far shows that the HTB code and
shaping script seems to work well and produces a fairly stable system. From
this point of view, it should be fairly easy to add in to v1.3.
But, developing the right webpage interface and debugging it will add time
and possibly another beta version.
BUT - it's such a cool feature!

Adding it as a patch seems to be the favourable course of action - and it
would turn out to be a fairly compact patch given that Mark is adding
(testing) the required kernel functionality and tc tool.
--
David Kilpatrick
da...@da...

Hi Ufuk ..

I took a quick look at those config page examples you pointed out, and I
feel they might be a little over the top. But let me explain why.
I stated in a previous email that the traffic shaping I was hoping to
develop would cater for the majority of xDSL and Cable users .. where if
upload bandwidth is saturated to capacity, download drops performance lags
behind as outgoing packets get dropped or severely queued. The WonderShaper
script (which addresses these issues) seemed to be the most suitable
implementation for traffic shaping which would benefit the majority of IPCop
users.

Essentially I felt the web config page would give you the ability to define
uplink and downlink speeds (ie 128/512 for ADSL) .. as well as protocols
and/or hosts to add to the high priority queue. Perhaps as an added measure,
provide the ability to change the ratio of bandwidth to be allocated between
high and low priority queues etc..

Then again, there will be users who would be keen to implement complex
traffic shaping rules for large installations. An equilibrium needs to be
established between functionality and practicality before a clear direction
can be taken on development of a web config page.

I started doing this as a solution to a specific problem I needed to solve.
Given correct development, Mark W feels this feature would be very highly
sought after.

That's my 2 cents, anyway :-)
--
David Kilpatrick
da...@da...

----- Original Message -----
From: "Ufuk Altinkaynak" <ufu...@wi...>
To: "David Kilpatrick" <da...@da...>;
<ipc...@li...>
Sent: Monday, March 31, 2003 7:52 PM
Subject: Re: [IPCop-devel] v1.3b3 - bandwidth control


> Helle David !
>
> David Kilpatrick wrote:
> > Today I installed the an updated kernel onto a IPCop v1.3b3 machine
> > today, and then applied the WonderShaper script.
> > Works like a charm, so far. I still have some 'tuning' of the
> > wondershaper script to suit my needs, but this is looking really
> > promising.
> >
> > RE: kernel update .. I had to enable CONFIG_NETFILTER_DEV.
> > Also, the version of tc supplied with v1.3b3 is not compatible with
> > the latest version of HTB.
> > Martin Devera has a binary available here:
> > http://luxik.cdi.cz/~devik/qos/htb/
> > That is required for HTB to work.
>
> Can you make the nessary files availble for download ??
> As i am also working on it (the problem is, that my time is soooo
limited),
> i would start to write the web-frontend, based on your work.
>
> BTW here are my used links for Qos
> http://users.belgacom.net/staf/qos/links.html
> http://lartc.org/wondershaper/
>
> Under http://www.docum.org/ i found realy interesting and for me most
> usefull information, i also aksed the developer last year to use some of
his
> code for a ipcop Project, an he said yes.
> under http://home.docum.org/qos/ runs a impressive Web Gui Demo
>
> But for the beginning a simple Web-Frontend would be enough or ???
>
> Regards
> Ufuk Altinkaynak
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

Hi

I know this will be hard, but I would like to implement aliases on the
green network, (shades of green).

I think a lot more people would start using ipcop if this could be
implemented.

I know of serveral companies who implement multiple lans, which go
through one firewall, this firewall does both internal and external
firewalling, where a green net to one would be red to the next however,
not the main red net.

Any ideas on how to start this?

What should the networks be called, as the are still going to be
accessed through the green interface? (light, dark & medium,)

Thanks

Mark=20

Mark Wormgoor wrote:

>> Just need to write the config page and I'm happy. Mark W, what are your
>> thoughts .. is this something worth considering for the 1.3 release?
>
>
> Well, the problem there is that 1.3 is going to be released in a 
> couple of weeks.  Rushing this in would mean finishing the webpage 
> before the weekend and releasing another beta in the weekend.  That 
> would give us one week to do some testing and the translators have a 
> week to translate it before we do a final beta.
> Even if we get it done, we risk introducing bugs into 1.3 at the last 
> moment.
> What does everyone think?

Is there a way to introduce it in v1.3 at a later date as a patch? I'm 
quite sure we can put a lot more new stuff in v1.3, but I think it's 
better to go to the market with a well tested release. Don't forget a 
lot of users are depending on us en the community expects us to ship 
only the best.

Tim

-- 
Tim Dobbelaere <ti...@do...> - http://tim.dobbelaere.com
[=== --- -- -
  Thawte Web of Trust Notary - http://www.thawte.com
  Linux Counter Country Manager for Belgium - http://counter.li.org
  IPCop Firewall: The Bad Packets Stop Here - http://www.ipcop.org
  PGP: 54E5 5C6B D369 4EAD 0FE2  7673 0F91 3095 069D 7943
[=== --- -- -

Hi,


> > From: Mark Wormgoor
> > Well, the problem there is that 1.3 is going to be released
> > in a couple
> > of weeks.  Rushing this in would mean finishing the webpage
> > before the
> > weekend and releasing another beta in the weekend.  That
> > would give us
> > one week to do some testing and the translators have a week
> > to translate
> > it before we do a final beta.
> > Even if we get it done, we risk introducing bugs into 1.3 at the last
> > moment.
> > What does everyone think?
>
> I say leave it out of 1.3 stable.  You can then look at releasing as a
> patch or 1.3.1 in a few months after it has been tested.

Ok, that's the way we'll go then.  I will include the CONFIG_NETFILTER_DEV
and the new tc binary though, since they are fairly safe and that makes it
easier to test the stuff.

Kind regards,

Mark

on 31/3/03 12:41 pm, Dave Roberts at da...@cz... wrote:

>> What does everyone think?
> 
> I say leave it out of 1.3 stable.  You can then look at releasing as a
> patch or 1.3.1 in a few months after it has been tested.
> 
> Dave

I agree, I think that's the way to proceed.

Eric

Mark Wormgoor wrote:
> Well, the problem there is that 1.3 is going to be released in a
> couple
> of weeks.  Rushing this in would mean finishing the webpage before the
> weekend and releasing another beta in the weekend.  That would give us
> one week to do some testing and the translators have a week to
> translate
> it before we do a final beta.
> Even if we get it done, we risk introducing bugs into 1.3 at the last
> moment.
> What does everyone think?

Well as i wrote i will write a "simple" webpage, maybe i can finish it this
weekend.

For doing that, what kind of minimum functions do you think we need ??

But back to your question Mark, i think to include it into 1.3 seems to be a
litlle bit late, but what about releasing it as a mod for 1.3 and including
it into 1.3x or 1.4 ???

Regards
Ufuk Altinkaynak

> From: Mark Wormgoor
> Well, the problem there is that 1.3 is going to be released=20
> in a couple=20
> of weeks.  Rushing this in would mean finishing the webpage=20
> before the=20
> weekend and releasing another beta in the weekend.  That=20
> would give us=20
> one week to do some testing and the translators have a week=20
> to translate=20
> it before we do a final beta.
> Even if we get it done, we risk introducing bugs into 1.3 at the last=20
> moment.
> What does everyone think?
>=20

I say leave it out of 1.3 stable.  You can then look at releasing as a
patch or 1.3.1 in a few months after it has been tested.

Dave