Re: [LARTC] Routing based on user id

2004-06-08 Thread Anton Glinkov
Hi, on page 3 of the lartc HOWTO one can read that it's possible to do routing based on user id. Can someone explain me how to do this? And is it somehow possible to set the DSCP depending on the user id? Thanks, Jürgen Jacob you can use the owner module in iptables iptables -m owner -h

[LARTC] Oops on tc-graph.pl of all things

2004-06-08 Thread Jason Boxman
It only makes a few calls to `tc`: rebecca:~# grep TC /home/jasonb/src/tc-graph.pl $BIN_TC=/sbin/tc; my @qdisc=`$BIN_TC -d qdisc show dev $DEV`; my @class=`$BIN_TC -d class show dev $DEV`; @filter=`$BIN_TC -d filter show dev $DEV parent $parent`; But something ultimately Oopses:

[LARTC] layers

2004-06-08 Thread Przemekk
iptables shows stats about packets in Layer 3, and tc ( htb ) is shaping also in layer 3. am i right? thanks in advance -- --- chaos, panic and disorder ... looks like my work is done here ---

[LARTC] Is it possible to control uplink in a NATted environment

2004-06-08 Thread Logu
Hi all, Given below ia the simple network diagram. I need to control uplink for the individual private network IPs as depicted in the diagram. Is this possible in a NATed environment using CBQ or HTB. I learnt that we can control only outgoing traffic. So if I control in the eth1 interface the

[LARTC] Routing - new table

2004-06-08 Thread Catalin Bucur
Hello, I have tested a simple thing in two version of Linux and there was a problem when I have used fwmark as a selector for rule lookups. As you can see below on the Slack, the test table doesn't have any label about fwmark. Is there an iproute problem? --

[LARTC] how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Greg Stark
[I sent this earlier but I guess the list is subscriber-only?] I just set up wondershaper, it has a simple filter on the downstream direction to limit the bandwidth usage: tc qdisc add dev $DEV handle : ingress tc filter add dev $DEV parent : protocol ip prio 50 u32 match ip src \

[LARTC] Blocking p2p traffic

2004-06-08 Thread Walter Wickersham
Greetings, I've searched, found ftwall, and some other commercial solutions, but am wondering if anyone on this list has any solutions using a linux firewall to block p2p traffic, more specifically Kazaa. Walter Wickersham ___ LARTC mailing list /

Re: [LARTC] how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Jason Boxman
On Tuesday 08 June 2004 14:35, Greg Stark wrote: [I sent this earlier but I guess the list is subscriber-only?] I just set up wondershaper, it has a simple filter on the downstream direction to limit the bandwidth usage: tc qdisc add dev $DEV handle : ingress tc filter add dev $DEV

Re: [LARTC] Blocking p2p traffic

2004-06-08 Thread Jason Boxman
On Tuesday 08 June 2004 15:15, Walter Wickersham wrote: Greetings, I've searched, found ftwall, and some other commercial solutions, but am wondering if anyone on this list has any solutions using a linux firewall to block p2p traffic, more specifically Kazaa. Yes. If you're using a 2.4.x

Re: [LARTC] Blocking p2p traffic

2004-06-08 Thread Horst Graffy
Am Dienstag, 8. Juni 2004 21:15 schrieb Walter Wickersham: Greetings, I've searched, found ftwall, and some other commercial solutions, but am wondering if anyone on this list has any solutions using a linux firewall to block p2p traffic, more specifically Kazaa. Hi, I've integrated ipp2p

Re: [LARTC] Oops on tc-graph.pl of all things

2004-06-08 Thread Andreas Klauer
Am Tuesday 08 June 2004 08:22 schrieb Jason Boxman: But something ultimately Oopses: rebecca:~# uname -a Linux rebecca 2.6.6 #1 Thu May 20 17:21:44 EDT 2004 i686 GNU/Linux I can reproduce this Oops in 2.4.26 using Jason's tc commands: `tc` configuration: tc qdisc add dev eth0 root handle

[LARTC] [ANNOUCE] iproute2 update

2004-06-08 Thread Stephen Hemminger
A new version of the iproute2 utilities is available to handle the new extensions for 2.6.7. * Based on the last known good version of iproute2 from Alexy * Included most of the vendor patches (except for the stupid ones). * Got rid of lots of the glibc workarounds, I

[LARTC] Re: [ANNOUCE] iproute2 update

2004-06-08 Thread Stephen Hemminger
On Tue, 8 Jun 2004 18:32:09 -0400 (EDT) [EMAIL PROTECTED] wrote: Stephen, Perhaps it is time to fix iproute2 interpretation of kbit/mbit/gbit. Currently, they are interpreted as powers of 2 (i.e. 10mbit = 10*1024*1024), which is absolutely incorrect when dealing with networking, as

[LARTC] Re: [ANNOUCE] iproute2 update

2004-06-08 Thread alex
But should we break existing scripts?? One possibility would be to make things case dependant (K = 1024 and k = 1000) or something like that. That does makes sense for entering data, however, for display of results, they need to be in one format. How about a global flags, -k/-K which would

Re: [LARTC] how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Damion de Soto
Greg, This is effective but is there any way to tell it to choose only certain kinds of streams for dropping packets? Minimally I would want to tell it to never drop any packets in a certain list of port numbers. ingress is rather weak. You can only really police with it. For what you want

[LARTC] Re: [ANNOUCE] iproute2 update

2004-06-08 Thread alex
Stephen, Perhaps it is time to fix iproute2 interpretation of kbit/mbit/gbit. Currently, they are interpreted as powers of 2 (i.e. 10mbit = 10*1024*1024), which is absolutely incorrect when dealing with networking, as line speeds are always interpreted in decimal. Example: 10Mbit ethernet is

Re: [LARTC] Is it possible to control uplink in a NATted environment

2004-06-08 Thread Damion de Soto
Hi Logu, So if I control in the eth1 interface the source IP will be masqueraded, and it may not result in the desired behaviour. Is there a solution to address this issue. You can use iptables to set different marks on the packets, and then filter based on those marks. regards, --

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Greg Stark
Damion de Soto [EMAIL PROTECTED] writes: You can create different ingress policers that only match specific ports, and give them different priorities, but that still won't work as well as using IMQ, or if your box is a gateway (and you are only shaping traffic going through it), then you can

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Damion de Soto
Greg, For some reason that hadn't occurred to me. That should work just fine. I guess I should mark the packets in iptables to avoid throttling traffic from gateway itself, or does match see the external ip? The only (common) time you need to use iptables to mark traffic, is when you're using

Re: [LARTC] Re: [ANNOUCE] iproute2 update

2004-06-08 Thread Andreas Klauer
Am Wednesday 09 June 2004 01:31 schrieb Stephen Hemminger: But should we break existing scripts?? Interesting questions - would it break scripts, or fix them? How many people did actually check wether k stands for 1024 or 1000 when writing their scripts? One possibility would be to make

[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

2004-06-08 Thread Greg Stark
Damion de Soto [EMAIL PROTECTED] writes: Greg, For some reason that hadn't occurred to me. That should work just fine. I guess I should mark the packets in iptables to avoid throttling traffic from gateway itself, or does match see the external ip? The only (common) time you need to use

Re: [LARTC] Re: [ANNOUCE] iproute2 update

2004-06-08 Thread Michael Renzmann
Hi. Andreas Klauer wrote: Interesting questions - would it break scripts, or fix them? How many people did actually check wether k stands for 1024 or 1000 when writing their scripts? I did. Bye, Mike ___ LARTC mailing list / [EMAIL PROTECTED]

Re: [LARTC] wondershaper under Debian

2004-06-08 Thread Fernando Favero
tks a lot for the help. I am brazilian and my wrote spanish is even worst than my english... but i understand you completely. This is the only place where i could find help.. i am trying to fix the problem for myself...soon or later i will find a solution. i hope so! muchas gracias hermano!