ipcop-devel Mailing List for IPCop Firewall

On 2010-11-29 21:50, Gilles Espinasse wrote:
> I don't think we really use nasm, unless we want to recompile entirely
> syslinux (we usually avoid that due to doc/distrib.txt notice).
> I have made that sometime to test a small patch to syslinux, but not that
> often.
> That should be the only issue if we want to test something there.

We could do something similar as we do for gdb.
To be honest I don't recall ever to build/use nasm.


Olaf

I don't think we really use nasm, unless we want to recompile entirely
syslinux (we usually avoid that due to doc/distrib.txt notice).
I have made that sometime to test a small patch to syslinux, but not that
often.
That should be the only issue if we want to test something there.

Upgrade to a more recent version is needed if we choose that path as
syslinux-4 require at least nasm-2.03 and we compile only 0.98.39

Gilles

On 11/28/2010 12:55 PM, Olaf Westrik wrote:
> On 2010-11-28 10:33, David W Studeman wrote:
>> On 11/26/2010 07:01 PM, David W Studeman wrote:
>> snip
>>>
>>> I plan on making a working lfs file (if none exist yet) that will
>>> compile the out of kernel driver and utility since both come in the same
>>> tarball. Which directory in the path should the binaries go into? /usr?
>>> /usr/local?
> 
> /usr/sbin is probably better.
> 
> 
>> Ok, I was easily able to make both the 0.11 driver and cli utility with
>> one lfs file and minor changes to make.sh, 1.9.19's update rootfiles and
>> adding a solos-pci rootfile in the 486 rootfiles. Here is a patch that
>> will apply all of the changes to r5179.
> 
> I've just applied with minor modifications.
> Thanks.
> 
> Please inform us as soon as the card is tested.
> 
> 
> Olaf
> 

Definitely will do. Thanks! I've put myself in a situation where I'll
have to make this work now. I had to do a year contract to get the low
per dsl line pricing. Everything should come together in the next three
weeks.
-- 
Dave Studeman
http://www.raqcop.com

On 2010-11-28 10:33, David W Studeman wrote:
> On 11/26/2010 07:01 PM, David W Studeman wrote:
> snip
>>
>> I plan on making a working lfs file (if none exist yet) that will
>> compile the out of kernel driver and utility since both come in the same
>> tarball. Which directory in the path should the binaries go into? /usr?
>> /usr/local?

/usr/sbin is probably better.


> Ok, I was easily able to make both the 0.11 driver and cli utility with
> one lfs file and minor changes to make.sh, 1.9.19's update rootfiles and
> adding a solos-pci rootfile in the 486 rootfiles. Here is a patch that
> will apply all of the changes to r5179.

I've just applied with minor modifications.
Thanks.

Please inform us as soon as the card is tested.


Olaf

On 2010-11-25 10:26, Guenter wrote:

> --- /usr/lib/ipcop/header.pl.orig       2010-11-23 06:24:40.000000000 +0100
> +++ /usr/lib/ipcop/header.pl    2010-11-25 10:15:29.000000000 +0100
> @@ -195,7 +195,7 @@
>                    if (@{$k2}[1] eq "$URI[0]\?$URI[1]" || (@{$k2}[1] eq
> $URI[0]&&  length($URI[1]) == 0)) {
>
>                        #if (@{$k2}[1] eq "$URI[0]") {
> -                    print "<b>@{$k2}[0]</b>";
> +                    print "<a href='@{$k2}[1]'
> style='text-decoration:none'><b>@{$k2}[0]</b></a>";
>                    }
>                    else {
>                        print "<a href='@{$k2}[1]'>@{$k2}[0]</a>";
>
> this patch does not change anything visible but only also provides a
> link for the current page.

Applied without the text-deco modification.
Thanks.


> Personally I would however remove the underline from all links since the
> bold printing is IMO enough to signal what's the current page.

Yes, but removing the underline makes it hard(er) to identify text as a 
link.


Olaf

Oops. It was a mis-named tar.gz. Here it is again with proper extension

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

On 11/26/2010 07:01 PM, David W Studeman wrote:
snip
> 
> I plan on making a working lfs file (if none exist yet) that will
> compile the out of kernel driver and utility since both come in the same
> tarball. Which directory in the path should the binaries go into? /usr?
> /usr/local?
> 

Ok, I was easily able to make both the 0.11 driver and cli utility with
one lfs file and minor changes to make.sh, 1.9.19's update rootfiles and
adding a solos-pci rootfile in the 486 rootfiles. Here is a patch that
will apply all of the changes to r5179.


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

 Since I am limited to 3000/768 adsl due to distance, have four lines
wired in the premises, and don't like my cable company. I decided to
order three more 3000/768 adsl lines at 25 bucks a pop and move the one
I have to the same isp for that price. Heck, I used to pay this much for
ISDN ten years ago. I also asked the gaining isp's General Manager about
my intentions. He mentioned that many of his customers do this but they
use external modems bridged into a load balancer. I want one aggregate
connection for red only.

So far the best solution I can see for my upcoming multiple adsl lines
is the four port Traverse Solos Pci.

Looking at the drivers on sourceforge and and comparing with the ones in
the 2.6.32 kernel, the 0.11 ones on sourceforge are far more updated
than the 0.7 version in 2.6.32. There is also a utility that can be
compiled  and used  by way of cli with some values that can be written
but the ones that can be read intrigue me. I was thinking that some
values can be added to one of the information pages in the gui or should
there be a separate page altogether for monitoring all the supported pci
dsl modems? Perhaps looking for certain values in /proc and skipping
altogether if they do not exist?

I plan on getting a four port solos to do this and bridging the four
adsl lines. My region for the line provider does not use pppo anything,
it's dhcp. Static addys would cost a bit more.

I plan on making a working lfs file (if none exist yet) that will
compile the out of kernel driver and utility since both come in the same
tarball. Which directory in the path should the binaries go into? /usr?
/usr/local?

The four port one is not cheap so I hope to be able to get one in a few
weeks.

Gilles, did you ever get that sample from Guy and do you already have
some of the work done but not committed? As far as I know, you only have
one line to test with?

OT: My current Traverse Viking works beautifully in bridged mode but
this is a self contained modem and the os does not see anything of it
except the realtek nic so it was not a challenge. To answer Andrew's
question a few years ago, yes the Viking can be bridged to act as a dumb
modem.
-- 
Dave Studeman
http://www.raqcop.com

Bugs item #3118612, was opened at 2010-11-25 17:20
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3118612&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.21
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash when Visting URL

Initial Comment:
IPCOP seems to crash intermittently. The server becomes completely unresponsive. The only instance I'm able to re-create it is visiting this address using my iPhone: http://www.360cities.net/london-photo-en.html. On PC this works fine. However it does seem to crash without the iPhone on the network as well.

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

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

Hi,
when you have switched off Javascvript then the submenu is printed as a 
sequence of links where the current page entry is printed bold but has 
no link functionality. This is bad since you cant cleanly reload the 
page, and using the browser's reload function is not recommended.
Therefore I've created the patch below which also provides a link for 
the current page so that its easy to reload it:

--- /usr/lib/ipcop/header.pl.orig       2010-11-23 06:24:40.000000000 +0100
+++ /usr/lib/ipcop/header.pl    2010-11-25 10:15:29.000000000 +0100
@@ -195,7 +195,7 @@
                  if (@{$k2}[1] eq "$URI[0]\?$URI[1]" || (@{$k2}[1] eq 
$URI[0] && length($URI[1]) == 0)) {

                      #if (@{$k2}[1] eq "$URI[0]") {
-                    print "<b>@{$k2}[0]</b>";
+                    print "<a href='@{$k2}[1]' 
style='text-decoration:none'><b>@{$k2}[0]</b></a>";
                  }
                  else {
                      print "<a href='@{$k2}[1]'>@{$k2}[0]</a>";

this patch does not change anything visible but only also provides a 
link for the current page.

Personally I would however remove the underline from all links since the 
bold printing is IMO enough to signal what's the current page.

Gün.

 As I mentioned elsewhere, I have been successfully running dual flash
raid on a Raq 550 and as of recent, a Raq 4i. I purposely booted it up
with one properly raid formatted card and the second one was
unformatted. Yes, Cobalts will boot up fine with one of the two drives
working as md0 and md1 as the partitions.

I noticed that there is a script in /lib/udev for this but on a raid
install it does not get moved to the udev in etc for me. Needless to say
it did not automatically rebuild the second unformatted drive into the
array. I was unsuccessful while trying to do it by hand with mdadm and
arguments. I know it was made deliberately so as to not make it too easy
to use or people will screw up installs with it so I cannot complain
about it. Is the lack of udev being moved over with raid also observed
on standard PC hardware or other architectures?

The red flagging on the status page works when you are in a degraded
raid state such as I described.
-- 
Dave Studeman
http://www.raqcop.com

On 11/19/2010 1:27 AM, Olaf Westrik wrote:
> On 2010-11-19 09:20, David W Studeman wrote:
>
>> I hadn't even considered this but it makes sense now that you pointed it
>> out. It sounds like downward shaping if anything would do more harm than
>> good but most likely, absolutely nothing.
>
> SVN #5146 adds a simple method to 'skip' downlink shaping, test results
> expected ;-)
>
>
> Olaf
>

Yes it saves with a blank download and I can certainly see downlink= 
(blank) in the settings file. The info tip saying it can be blank is a 
nice touch as well.
-- 
Dave Studeman
http:/www.raqcop.com

On 2010-11-19 09:20, David W Studeman wrote:

> I hadn't even considered this but it makes sense now that you pointed it
> out. It sounds like downward shaping if anything would do more harm than
> good but most likely, absolutely nothing.

SVN #5146 adds a simple method to 'skip' downlink shaping, test results 
expected ;-)


Olaf

On 11/19/2010 12:11 AM, Olaf Westrik wrote:
> On 2010-11-19 08:52, David W Studeman wrote:
>> On 11/18/2010 11:34 PM, Olaf Westrik wrote:
>
>
>>> What we could probably just as well remove from our code, is shaping for
>>> downlink.
>
>> I've often heard of this. The part that concerns me is that even while
>> the uplink is usually lower and is the limitation on how many
>> simultaneous g.711 calls you can have going at the same time, we tend to
>> have heavy downloads at times, especially pulling an iso.
>>
>> I think that while the upload shaping is important for uploads such as
>> sharing etc, the download shaping is no less important. It wouldn't be
>> bad to have heavy downloads not interfere with shoutcast streams as well
>> even though I am biased. The latter has to be done by class as most
>> modern streams use standard port 80 and you don't want to give
>> everything at port 80 high priority such as browsing or it defeats part
>> of the purpose.
>
> Well yes, but there is not that much we can do there.
> Local speed (i.e. traffic to green, blue etc.) is more often than not
> higher than downlink speed. So there is not much (or even nothing at
> all) to queue up and change delivery sequence.
>
> It is the ISP that can control delivery, as congestion takes place
> before the slowest path.
>
>
> Olaf

I hadn't even considered this but it makes sense now that you pointed it 
out. It sounds like downward shaping if anything would do more harm than 
good but most likely, absolutely nothing. I'm sure most of use do not 
have 100mbs down speed with our internet connections much less 1gbs for 
those that run them on their cops.
-- 
Dave Studeman
http:/www.raqcop.com

On 2010-11-19 08:52, David W Studeman wrote:
> On 11/18/2010 11:34 PM, Olaf Westrik wrote:


>> What we could probably just as well remove from our code, is shaping for
>> downlink.

> I've often heard of this. The part that concerns me is that even while
> the uplink is usually lower and is the limitation on how many
> simultaneous g.711 calls you can have going at the same time, we tend to
> have heavy downloads at times, especially pulling an iso.
>
> I think that while the upload shaping is important for uploads such as
> sharing etc, the download shaping is no less important. It wouldn't be
> bad to have heavy downloads not interfere with shoutcast streams as well
> even though I am biased. The latter has to be done by class as most
> modern streams use standard port 80 and you don't want to give
> everything at port 80 high priority such as browsing or it defeats part
> of the purpose.

Well yes, but there is not that much we can do there.
Local speed (i.e. traffic to green, blue etc.) is more often than not 
higher than downlink speed. So there is not much (or even nothing at 
all) to queue up and change delivery sequence.

It is the ISP that can control delivery, as congestion takes place 
before the slowest path.


Olaf

On 11/18/2010 11:34 PM, Olaf Westrik wrote:
> On 2010-11-18 11:19, David W Studeman wrote:
>> On 11/18/2010 12:59 AM, Robert Ladyman wrote:
>>> For shaping on 1.4.* I've used SuperShaper-SOHO for a number of years. It's
>>> not port-based but class-based (VOIP, SSH, or whatever) and you can divide
>>> your shaping accordingly.  No idea yet whether it would work with 2.0, but
>>> it's
>
> As it does not use any of the IPCop configuration settings, it would
> work with 2.0.
>
> It appears to be a combination of ports and classes, some of the ports
> are fairly specific and won't be needed (or useful) in many cases.
>
>
>> It would appear that it uses the tools that are already present in
>> IPCop. Interestingly, the author used IPCop to develop it on in the
>> first place. It comes in init script form and needs minor hand editing
>> for your connection.
>>
>> Interesting indeed.
>
> Something we could do:
> add class for VoIP traffic and put RTP data in there. Assuming all play
> nice (set the ToS properly), that would work.
> add config option to make 'VoIP prioritizing' opt-in.
>
>
> What we could probably just as well remove from our code, is shaping for
> downlink.
>
>
> Olaf

I've often heard of this. The part that concerns me is that even while 
the uplink is usually lower and is the limitation on how many 
simultaneous g.711 calls you can have going at the same time, we tend to 
have heavy downloads at times, especially pulling an iso.

I think that while the upload shaping is important for uploads such as 
sharing etc, the download shaping is no less important. It wouldn't be 
bad to have heavy downloads not interfere with shoutcast streams as well 
even though I am biased. The latter has to be done by class as most 
modern streams use standard port 80 and you don't want to give 
everything at port 80 high priority such as browsing or it defeats part 
of the purpose.

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

OT: I use my Audiotrons a lot and with the demise of Turtle Radio, it is 
set to look on my server for a station list.

On 2010-11-18 11:19, David W Studeman wrote:
> On 11/18/2010 12:59 AM, Robert Ladyman wrote:
>> For shaping on 1.4.* I've used SuperShaper-SOHO for a number of years. It's
>> not port-based but class-based (VOIP, SSH, or whatever) and you can divide
>> your shaping accordingly.  No idea yet whether it would work with 2.0, but
>> it's

As it does not use any of the IPCop configuration settings, it would 
work with 2.0.

It appears to be a combination of ports and classes, some of the ports 
are fairly specific and won't be needed (or useful) in many cases.


> It would appear that it uses the tools that are already present in
> IPCop. Interestingly, the author used IPCop to develop it on in the
> first place. It comes in init script form and needs minor hand editing
> for your connection.
>
> Interesting indeed.

Something we could do:
add class for VoIP traffic and put RTP data in there. Assuming all play 
nice (set the ToS properly), that would work.
add config option to make 'VoIP prioritizing' opt-in.


What we could probably just as well remove from our code, is shaping for 
downlink.


Olaf

On 11/18/2010 12:59 AM, Robert Ladyman wrote:
> For shaping on 1.4.* I've used SuperShaper-SOHO for a number of years. It's 
> not port-based but class-based (VOIP, SSH, or whatever) and you can divide 
> your shaping accordingly.  No idea yet whether it would work with 2.0, but 
> it's 
> 
> Apologies if this is a completely wrong suggestion.
> 
> RJL
> 
> 

It would appear that it uses the tools that are already present in
IPCop. Interestingly, the author used IPCop to develop it on in the
first place. It comes in init script form and needs minor hand editing
for your connection.

Interesting indeed.


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

PS: Try to refrain from top posting if possible.

For shaping on 1.4.* I've used SuperShaper-SOHO for a number of years. It's 
not port-based but class-based (VOIP, SSH, or whatever) and you can divide 
your shaping accordingly.  No idea yet whether it would work with 2.0, but 
it's 

Apologies if this is a completely wrong suggestion.

RJL


> On 2010-11-18 08:38, David W Studeman wrote:
>  >> Shaping will allow port ranges just as firewall/services does.
>  >> restartshaping then throws errors though (Illegal "match"), indicating
>  >> tc does not like it.
>  >
>  >    You are correct. I just confirmed this, it does NOT like that!
>  >
>  > Sadly, manually adding the port range as we discussed was written as a
>  > solution on the IPCops forum about five years ago and because you can
>  > see it in the gui after that and hitting save does not produce an error,
>  > people mistakenly thought it must be working then. In those days I did
>  > not need shaping so I did not tinker with it.
> 
> Manually editing config files is always good for 1 or 2 surprises.
> 
> >> The solution for ranges would be to use MARKing via iptables and then
> >> filter on MARKs.
> >
> > This seems logical. A few years back when layer 7 patched kernels were
> > discussed, you had mentioned that the direction for shaping was moving
> > more toward userspace so it might not be prudent to go that direction
> > just yet. Does this seem to be playing out this way?
> 
> Sort of. l7 blocking was discouraged in favour of 'l7-shaping', that
> would also explain better the name l7-filter and not l7-block.
> 
> The building blocks iptables and tc allow one to build fine-grained
> control. A klick-klick-save solution that works for everybody,
> everywhere, everytime, is something wholly different tho.
> 
> With the demise of the l7 project one would clearly need to rethink all
> this of course.
> 
> > At least one Raqcop user showed interest in using the layer 7 addon
> > which meant that he wanted to know if I was looking to make a Cobalt
> > bootable layer 7 patched kernel. Markus's addon requires the kernel to
> > already be patched. This is of course for the current 1.4.21 version.
> 
> I see no future when going that road, so I would not invest time there
> if I were you.
> 
> >>> Is the plan to stick with wondershaper?
> >>
> >> Unless someone suggests (and implements) something better: yes.
> >
> > So far I have seen that traffic shaping in any form can be tricky and
> > easily misused.
> 
> It is not trivial to run tests, one would need to generate specific
> traffic and measure the results, when doing shaping.
> 
> > For the time being I will just stick to the script I attached. I added
> > back my individual entries for ports 10000 to 20000 with the script and
> > issued a restartshaping. It took a while to restart as you could
> > probably guess with over 10000 lines in the file but it did not complain.
> 
> It'll probably slow you down a bit, yes ;-)
> Not sure how well tc filtering scales with many entries.
> 
> 
> The 'problem' with MARKing is that one can only set 1 MARK, in our case
> we are MARKing internal traffic 'bouncing off' portforwards, and, in the
> case of IPCop v2, IPsec traffic.
> 
> 
> For ordinary shaping (not l7 related) a better integrated solution would
> probably be something like this:
> - firewall rules (as exist in IPCop v2) would become an additional field
> offering low and high priority.
> - all other traffic uses medium priority.
> 
> 
> Working patches are welcome :-)
> 
> 
> Olaf
> 
> ---------------------------------------------------------------------------
> --- Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
> 

-- 
Robert Ladyman
File-Away Limited
3 Ralston Business Centre, Newtyle, Blairgowrie
Perthshire  PH12 8TL SCOTLAND
Tel: +44 (0) 1828 898 158
Mobile: +44 (0) 7732 771 649
http://www.file-away.co.uk

============================================
Registered Office: 32 Church Street, Newtyle, Blairgowrie
Perthshire, PH12 8TZ SCOTLAND
Registered in Scotland, Company Number SC222086

On 11/18/2010 12:32 AM, Olaf Westrik wrote:
> On 2010-11-18 08:38, David W Studeman wrote:
> 
> 
>  >> Shaping will allow port ranges just as firewall/services does.
>  >> restartshaping then throws errors though (Illegal "match"), indicating
>  >> tc does not like it.
>  >
>  >    You are correct. I just confirmed this, it does NOT like that!
>  >
>  > Sadly, manually adding the port range as we discussed was written as a
>  > solution on the IPCops forum about five years ago and because you can
>  > see it in the gui after that and hitting save does not produce an error,
>  > people mistakenly thought it must be working then. In those days I did
>  > not need shaping so I did not tinker with it.
> 
> Manually editing config files is always good for 1 or 2 surprises.
> 
> 
>>> The solution for ranges would be to use MARKing via iptables and then
>>> filter on MARKs.
>>
>> This seems logical. A few years back when layer 7 patched kernels were
>> discussed, you had mentioned that the direction for shaping was moving
>> more toward userspace so it might not be prudent to go that direction
>> just yet. Does this seem to be playing out this way?
> 
> Sort of. l7 blocking was discouraged in favour of 'l7-shaping', that 
> would also explain better the name l7-filter and not l7-block.
> 
> The building blocks iptables and tc allow one to build fine-grained 
> control. A klick-klick-save solution that works for everybody, 
> everywhere, everytime, is something wholly different tho.
> 
> With the demise of the l7 project one would clearly need to rethink all 
> this of course.
> 
> 
>> At least one Raqcop user showed interest in using the layer 7 addon
>> which meant that he wanted to know if I was looking to make a Cobalt
>> bootable layer 7 patched kernel. Markus's addon requires the kernel to
>> already be patched. This is of course for the current 1.4.21 version.
> 
> I see no future when going that road, so I would not invest time there 
> if I were you.

Sounds reasonable. This is not unlike the reason I gave him for not
wanting to spend any time doing this at that time.
> 
> 
>>>> Is the plan to stick with wondershaper?
>>>
>>> Unless someone suggests (and implements) something better: yes.
>>>
>> So far I have seen that traffic shaping in any form can be tricky and
>> easily misused.
> 
> It is not trivial to run tests, one would need to generate specific 
> traffic and measure the results, when doing shaping.
> 
> 
>> For the time being I will just stick to the script I attached. I added
>> back my individual entries for ports 10000 to 20000 with the script and
>> issued a restartshaping. It took a while to restart as you could
>> probably guess with over 10000 lines in the file but it did not complain.
> 
> It'll probably slow you down a bit, yes ;-)
> Not sure how well tc filtering scales with many entries.

The jury is still out on that one. Have I overwhelmed it enough to make
it useless?

> The 'problem' with MARKing is that one can only set 1 MARK, in our case 
> we are MARKing internal traffic 'bouncing off' portforwards, and, in the 
> case of IPCop v2, IPsec traffic.
> 
> 
> For ordinary shaping (not l7 related) a better integrated solution would 
> probably be something like this:
> - firewall rules (as exist in IPCop v2) would become an additional field 
> offering low and high priority.
> - all other traffic uses medium priority.
> 
> 
> Working patches are welcome :-)
> 
> 
> Olaf

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

On 2010-11-18 08:38, David W Studeman wrote:


 >> Shaping will allow port ranges just as firewall/services does.
 >> restartshaping then throws errors though (Illegal "match"), indicating
 >> tc does not like it.
 >
 >    You are correct. I just confirmed this, it does NOT like that!
 >
 > Sadly, manually adding the port range as we discussed was written as a
 > solution on the IPCops forum about five years ago and because you can
 > see it in the gui after that and hitting save does not produce an error,
 > people mistakenly thought it must be working then. In those days I did
 > not need shaping so I did not tinker with it.

Manually editing config files is always good for 1 or 2 surprises.


>> The solution for ranges would be to use MARKing via iptables and then
>> filter on MARKs.
>
> This seems logical. A few years back when layer 7 patched kernels were
> discussed, you had mentioned that the direction for shaping was moving
> more toward userspace so it might not be prudent to go that direction
> just yet. Does this seem to be playing out this way?

Sort of. l7 blocking was discouraged in favour of 'l7-shaping', that 
would also explain better the name l7-filter and not l7-block.

The building blocks iptables and tc allow one to build fine-grained 
control. A klick-klick-save solution that works for everybody, 
everywhere, everytime, is something wholly different tho.

With the demise of the l7 project one would clearly need to rethink all 
this of course.


> At least one Raqcop user showed interest in using the layer 7 addon
> which meant that he wanted to know if I was looking to make a Cobalt
> bootable layer 7 patched kernel. Markus's addon requires the kernel to
> already be patched. This is of course for the current 1.4.21 version.

I see no future when going that road, so I would not invest time there 
if I were you.


>>> Is the plan to stick with wondershaper?
>>
>> Unless someone suggests (and implements) something better: yes.
>>
> So far I have seen that traffic shaping in any form can be tricky and
> easily misused.

It is not trivial to run tests, one would need to generate specific 
traffic and measure the results, when doing shaping.


> For the time being I will just stick to the script I attached. I added
> back my individual entries for ports 10000 to 20000 with the script and
> issued a restartshaping. It took a while to restart as you could
> probably guess with over 10000 lines in the file but it did not complain.

It'll probably slow you down a bit, yes ;-)
Not sure how well tc filtering scales with many entries.


The 'problem' with MARKing is that one can only set 1 MARK, in our case 
we are MARKing internal traffic 'bouncing off' portforwards, and, in the 
case of IPCop v2, IPsec traffic.


For ordinary shaping (not l7 related) a better integrated solution would 
probably be something like this:
- firewall rules (as exist in IPCop v2) would become an additional field 
offering low and high priority.
- all other traffic uses medium priority.


Working patches are welcome :-)


Olaf

On 11/17/2010 4:56 AM, Olaf Westrik wrote:
> On 2010-11-16 01:19, David W Studeman wrote:
>> It appears as though traffic shaping differs very little from that of
>> 1.4 as far as the web gui goes. I believe that port ranges are supposed
>> to work while using the 2.6 kernel. In such a case port ranges would be
>> added as such startport:endport. An example would be that I want all
>> ports from 10000 to 20000 to have high priority for VOIP RTP traffic so
>> I would enter it 10000:20000.
>>
>> What I have already is a script I found in an Australian forum by a user
>> named syn-tax (which I fine tuned by hand to look perfect when viewing
>> in the web gui) which will manually add an entire range one line at a
>> time to /var/ipcop/shaping/config. The script works fine on 1.9.x just
>> as well as 1.4.x as of current. In my case, I end up with a 160KB file
>> with over 10000 entries (the 10000-20000 plus SIP etc). As near as I can
>> tell, this works fine but ranges would be a lot cleaner if possible.
>
> IIRC tc does not allow port ranges, so there is a reason to prohibit
> port ranges in the GUI.
>
> If you modify this:
> Index: html/cgi-bin/shaping.cgi
> ===================================================================
> --- html/cgi-bin/shaping.cgi    (revision 5136)
> +++ html/cgi-bin/shaping.cgi    (working copy)
> @@ -84,7 +84,7 @@
>    if ($shapingsettings{'ACTION'} eq $Lang::tr{'add'}) {
>        unless ($shapingsettings{'SERVICE_PROT'} =~ /^(tcp|udp)$/)  {
> $errormessage = $Lang::tr{'invalid input'}; }
>        unless ($shapingsettings{'SERVICE_PRIO'} =~ /^(10|20|30)$/) {
> $errormessage = $Lang::tr{'invalid input'}; }
> -    unless (&General::validport($shapingsettings{'SERVICE_PORT'})) {
> $errormessage = $Lang::tr{'invalid port'}; }
> +    unless (&General::validportrange($shapingsettings{'SERVICE_PORT'},
> 'dest') eq '') { $errormessage = $Lang::tr{'invalid port'}; }
>
>        if (!$errormessage) {
>            if ($shapingsettings{'EDITING'} eq 'no') {
>
>
> Shaping will allow port ranges just as firewall/services does.
> restartshaping then throws errors though (Illegal "match"), indicating
> tc does not like it.

  You are correct. I just confirmed this, it does NOT like that!

Sadly, manually adding the port range as we discussed was written as a 
solution on the IPCops forum about five years ago and because you can 
see it in the gui after that and hitting save does not produce an error, 
people mistakenly thought it must be working then. In those days I did 
not need shaping so I did not tinker with it.

> The solution for ranges would be to use MARKing via iptables and then
> filter on MARKs.

This seems logical. A few years back when layer 7 patched kernels were 
discussed, you had mentioned that the direction for shaping was moving 
more toward userspace so it might not be prudent to go that direction 
just yet. Does this seem to be playing out this way?

At least one Raqcop user showed interest in using the layer 7 addon 
which meant that he wanted to know if I was looking to make a Cobalt 
bootable layer 7 patched kernel. Markus's addon requires the kernel to 
already be patched. This is of course for the current 1.4.21 version.
>
>> Is the plan to stick with wondershaper?
>
> Unless someone suggests (and implements) something better: yes.
>
So far I have seen that traffic shaping in any form can be tricky and 
easily misused.

For the time being I will just stick to the script I attached. I added 
back my individual entries for ports 10000 to 20000 with the script and 
issued a restartshaping. It took a while to restart as you could 
probably guess with over 10000 lines in the file but it did not complain.

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

On 2010-11-16 01:19, David W Studeman wrote:
> It appears as though traffic shaping differs very little from that of
> 1.4 as far as the web gui goes. I believe that port ranges are supposed
> to work while using the 2.6 kernel. In such a case port ranges would be
> added as such startport:endport. An example would be that I want all
> ports from 10000 to 20000 to have high priority for VOIP RTP traffic so
> I would enter it 10000:20000.
>
> What I have already is a script I found in an Australian forum by a user
> named syn-tax (which I fine tuned by hand to look perfect when viewing
> in the web gui) which will manually add an entire range one line at a
> time to /var/ipcop/shaping/config. The script works fine on 1.9.x just
> as well as 1.4.x as of current. In my case, I end up with a 160KB file
> with over 10000 entries (the 10000-20000 plus SIP etc). As near as I can
> tell, this works fine but ranges would be a lot cleaner if possible.

IIRC tc does not allow port ranges, so there is a reason to prohibit 
port ranges in the GUI.

If you modify this:
Index: html/cgi-bin/shaping.cgi
===================================================================
--- html/cgi-bin/shaping.cgi    (revision 5136)
+++ html/cgi-bin/shaping.cgi    (working copy)
@@ -84,7 +84,7 @@
  if ($shapingsettings{'ACTION'} eq $Lang::tr{'add'}) {
      unless ($shapingsettings{'SERVICE_PROT'} =~ /^(tcp|udp)$/)  { 
$errormessage = $Lang::tr{'invalid input'}; }
      unless ($shapingsettings{'SERVICE_PRIO'} =~ /^(10|20|30)$/) { 
$errormessage = $Lang::tr{'invalid input'}; }
-    unless (&General::validport($shapingsettings{'SERVICE_PORT'})) { 
$errormessage = $Lang::tr{'invalid port'}; }
+    unless (&General::validportrange($shapingsettings{'SERVICE_PORT'}, 
'dest') eq '') { $errormessage = $Lang::tr{'invalid port'}; }

      if (!$errormessage) {
          if ($shapingsettings{'EDITING'} eq 'no') {


Shaping will allow port ranges just as firewall/services does.
restartshaping then throws errors though (Illegal "match"), indicating 
tc does not like it.

The solution for ranges would be to use MARKing via iptables and then 
filter on MARKs.


> Is the plan to stick with wondershaper?

Unless someone suggests (and implements) something better: yes.


Olaf

On 11/15/2010 4:19 PM, David W Studeman wrote:
> It appears as though traffic shaping differs very little from that of
> 1.4 as far as the web gui goes. I believe that port ranges are supposed
> to work while using the 2.6 kernel. In such a case port ranges would be
> added as such startport:endport. An example would be that I want all
> ports from 10000 to 20000 to have high priority for VOIP RTP traffic so
> I would enter it 10000:20000.
>
> What I have already is a script I found in an Australian forum by a user
> named syn-tax (which I fine tuned by hand to look perfect when viewing
> in the web gui) which will manually add an entire range one line at a
> time to /var/ipcop/shaping/config. The script works fine on 1.9.x just
> as well as 1.4.x as of current. In my case, I end up with a 160KB file
> with over 10000 entries (the 10000-20000 plus SIP etc). As near as I can
> tell, this works fine but ranges would be a lot cleaner if possible.
>
> Is the plan to stick with wondershaper?
>
>

Looking into this further and looking back in IPCop forums, it would 
appear that the port range as 1234:1234 will work if hand edited into 
the config file. When doing this, it does show up in the web gui 
correctly even though you cannot enter it in the web gui this way.

I am trying this with my daily 1.4.21 firewall/router. It's actually the 
upload bandwidth that will likely affect VOIP with asymmetrical 
connections as most of us have. Of course jitter and latency are more 
likely to be an enemy than sheer bandwidth.

My config file looks like:

udp,53,10,on
udp,123,10,on
udp,5061,10,on
udp,5060,10,on
tcp,53,10,on
tcp,443,20,on
tcp,80,20,on
tcp,8080,20,on
udp,10000:20000,10,on

I'll test this and see how well this works.

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

On 11/15/2010 05:12 AM, Olaf Westrik wrote:
> 
>>> I think we should humbly ask and see what happen.
>>> Did you want that I report to tar list?
>>
>> That would be great, thanks.
> 
> After I found the list and archives, I saw the patch from Paul.
> Patch is OK.
> 
> I'll add and commit the patch in a few seconds.
> 
> Thanks Gilles.
> 
> 
> Olaf
> 

That fixed the backup creation issue, it works again, thanks.
-- 
Dave Studeman
http://www.raqcop.com