Re: [LARTC] Routing based on user id
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 for DSCP you can use -j DSCP here is a solution with fwmark: e.g iptables -t mangle -A OUTPUT -m owner --uid-owner 0 -j MARK --set-mark 1 and then ip rule add fwmark 0x01 table 1 after that you add all the route in table 1 ip route add .. via . table 1 -- Anton Glinkov network administrator ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Oops on tc-graph.pl of all things
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: rebecca:~# uname -a Linux rebecca 2.6.6 #1 Thu May 20 17:21:44 EDT 2004 i686 GNU/Linux faith:~# gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.3/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.3 (Debian 20040401) I also have Layer7-Kernel v0.7 patch applied to my kernel. HTB init, kernel part version 3.16 htb: class 10090 isn't work conserving ?! Unable to handle kernel NULL pointer dereference at virtual address printing eip: *pde = Oops: [#1] CPU:0 EIP:0060:[]Not tainted EFLAGS: 00010246 (2.6.6) EIP is at 0x0 eax: ebx: c61d9600 ecx: 0002 edx: c88277c0 esi: edi: c6669144 ebp: c757c664 esp: c6181bd0 ds: 007b es: 007b ss: 0068 Process tc (pid: 960, threadinfo=c618 task=c67ea150) Stack: c0228d44 c3e54148 1000 c013e0ca c61bd91c c78f3cc4 c61bd864 c61bd85c c88277c0 c3e54148 c1135400 c61d9600 0f60 c0215f47 1000 00d0 c40e42e0 c40e42e0 c40e42e0 c61d9600 Call Trace: [c0228d44] tc_dump_tfilter+0xb4/0x260 [c013e0ca] __vma_link+0x3a/0xa0 [c0215f47] alloc_skb+0x47/0xf0 [c022a539] netlink_dump+0x59/0x1b0 [c022a737] netlink_dump_start+0xa7/0xf0 [c0222bff] rtnetlink_rcv+0x34f/0x390 [c0228c90] tc_dump_tfilter+0x0/0x260 [c02228a0] rtnetlink_done+0x0/0x10 [c01bcd2e] copy_to_user+0x3e/0x50 [c022a3ba] netlink_data_ready+0x5a/0x70 [c0229a43] netlink_sendskb+0xa3/0xb0 [c022a042] netlink_sendmsg+0x212/0x310 [c0212948] sock_sendmsg+0x98/0xd0 [c01bcd82] copy_from_user+0x42/0x70 [c01bcd82] copy_from_user+0x42/0x70 [c0217c4c] verify_iovec+0x3c/0xa0 [c02141cf] sys_sendmsg+0x18f/0x1f0 [c013d106] do_no_page+0x196/0x320 [c013d470] handle_mm_fault+0xe0/0x150 [c0114c4c] do_page_fault+0x12c/0x530 [c01bcd82] copy_from_user+0x42/0x70 [c0214672] sys_socketcall+0x242/0x260 [c0114b20] do_page_fault+0x0/0x530 [c01060b9] error_code+0x2d/0x38 [c0105eaf] syscall_call+0x7/0xb Code: Bad EIP value. `tc` configuration: tc qdisc add dev eth0 root handle 1: htb default 90 tc class add dev eth0 parent 1: classid 1:1 htb rate 160kbit ceil 160kbit tc class add dev eth0 parent 1:1 classid 1:90 htb rate 160kbit ceil 160kbit tc qdisc add dev eth0 parent 1:90 handle 2: prio bands 4 tc qdisc add dev eth0 parent 2:1 handle 10: sfq perturb 20 tc qdisc add dev eth0 parent 2:2 handle 20: sfq perturb 20 tc qdisc add dev eth0 parent 2:3 handle 30: sfq perturb 20 tc qdisc add dev eth0 parent 2:4 handle 40: tbf rate 152kbit buffer 1600 limit 3000 Afterwards, `tc` always hangs. Even `ifconfig` hangs. The box has to be toggled manually to bring it back. Thoughts anyone? Thanks. -- 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] layers
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 mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Is it possible to control uplink in a NATted environment
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 source IP will be masqueraded, and it may not result in the desired behaviour. Is there a solution to address this issue. GATEWAY private net work |---| ---| |Internet eth0 |---| eth1 NAT Thanks -logu ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Routing - new table
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? -- # cat /etc/fedora-release Fedora Core release 2 (Tettnang) # uname -r 2.6.5-1.358 # rpm -qa|grep iproute iproute-2.4.7-14 # cat /etc/iproute2/rt_tables 5 test # ip rule add fwmark 5 table 5 # ip ru sh 0: from all lookup local 32765: from all fwmark 0x5 lookup test 32766: from all lookup main 32767: from all lookup default -- # cat /etc/slackware-version Slackware 8.1 # uname -r 2.4.26 # ls iproute* iproute2-2.4.7-now-ss020116-try.tar.gz # cat /etc/iproute2/rt_tables 255 local 254 main 253 default 0 unspec 5 test # ip rule add fwmark 5 table 5 # ip ru sh 0: from all lookup local 32765: from all lookup test 32766: from all lookup main 32767: from all lookup default -- -- Catalin Bucur mailto:[EMAIL PROTECTED] NOC @ Genius Network SRL - Galati - Romania ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] how flexible is ingress traffic policing to bandwidth limit?
[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 \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
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.
Ideally I would want it to never drop any packets that fall into the 1:10
flowid that is set up earlier in wondershaper. I'm unclear if that's possible
though since that flowid is set up for outgoing packets, and some of the
filters don't even make sense for incoming packets (TOS for example).
But even if I could just tell it to never choose packets from particular
ports, that would satisfy my immediate needs.
--
greg
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Blocking p2p traffic
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] how flexible is ingress traffic policing to bandwidth limit?
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 parent : protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
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 most people setup the IMQ[1] device and you egress filters on it to
control what is shaped and how.
[1] http://trash.net/~kaber/imq/
snip
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Blocking p2p traffic
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 series kernel, check out IPP2P[1]. You'll also need the CONNMARK extension for IPTables. You can then easily drop p2p traffic. If you're using a 2.6.x series kernel, check out L7-Filter[2]. You can easily drop p2p traffic (and other nifty application level protocol matches) too. [1] http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html [2] http://l7-filter.sourceforge.net/ Enjoy! Walter Wickersham ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Blocking p2p traffic
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 (http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html) in my shorewall-firewall (http://www.shorewall.net/) setup: in /etc/shorewall/start (create the file if not there) ### # ipp2p ### echo -n starting ipp2p # ip2pp for appleJuice echo -n (appleJuice) /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --apple -j DROP /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --apple -j LOG --log-level 6 \ --log-prefix ipp2p: appleJuice-traffic # ip2pp for dc echo -n (DC) /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --dc -j DROP /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --dc -j LOG --log-level 6 \ --log-prefix ipp2p: dc-traffic # ip2pp for gnutella echo -n (gnutella) /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --gnu -j DROP /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --gnu -j LOG --log-level 6 \ --log-prefix ipp2p: gnutella-traffic # ip2pp for eDonkey echo -n (eDonkey) /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --edk -j DROP /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --edk -j LOG --log-level 6 \ --log-prefix ipp2p: eDonkey-traffic # ip2pp for kazaa echo -n (kazaa) /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --kazaa -j DROP /usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --kazaa -j LOG --log-level 6 \ --log-prefix ipp2p: kazaa-traffic # ip2pp for BitTorrent (allowed ;) echo -n (BitTorrent) #/usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --bit -j DROP #/usr/sbin/iptables -I FORWARD -p tcp -m ipp2p --bit -j LOG --log-level 6 \ --log-prefix ipp2p: BitTorrent-traffic echo echo ipp2p started and in /etc/shorewall/modules # ipp2p (p2p Traffic) loadmodule ipp2p work's like a charm ;)) I don't use the connmark stuff at the moment, because I have not found the time to recompile my kernel hope this helps Toni Walter Wickersham ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Oops on tc-graph.pl of all things
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 1: htb default 90 tc class add dev eth0 parent 1: classid 1:1 htb rate 160kbit ceil 160kbit tc class add dev eth0 parent 1:1 classid 1:90 htb rate 160kbit ceil 160kbit tc qdisc add dev eth0 parent 1:90 handle 2: prio bands 4 tc qdisc add dev eth0 parent 2:1 handle 10: sfq perturb 20 tc qdisc add dev eth0 parent 2:2 handle 20: sfq perturb 20 tc qdisc add dev eth0 parent 2:3 handle 30: sfq perturb 20 tc qdisc add dev eth0 parent 2:4 handle 40: tbf rate 152kbit buffer 1600 limit 3000 ...and running my tc-graph.pl script (http://www.metamorpher.de/files/tc-graph.pl) afterwards (you probably have to change two variables at the top of the script, namely DEV for the device and BIN_TC for the location of your tc binary). It kind of killed my router, my NIC didn't get detected after reboot anymore, but that may have been just a really, really bad coincidence. Someone on this list who is particularly interested in this stuff? Andreas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] [ANNOUCE] iproute2 update
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 intend this to build and run on 2.6 (and 2.4) only. * Fixed some parsing and formatting bugs. * Added gigabit as a rate. * Added HTB and delay scheduler * Added support for new tcp_info extensions to ss The website is: http://developer.osdl.org/dev/iproute2 and the download is in: http://developer.osdl.org/dev/iproute2/download This version builds with 2.6.7 as the kernel include files, so either have the files in /usr/include/linux up to date or modify the top level Makefile to point to a kernel build. Will workout a way to build on 2.4 next. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: [ANNOUCE] iproute2 update
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 line speeds are always interpreted in decimal. Example: 10Mbit ethernet is 10 000 000 bits/second. Someone who may be trying to rate-limit outbound traffic is bound for a surprise when tc's 10mbit does not match physical line characteristic. Other examples: 28k modem is 28000 bit/s, 56k is 56000, OC-3 SONET (155Mbit) is 15500 bit/s, etc. There isn't a technology that is quoted with kbits meaning 1024bit/s. But should we break existing scripts?? One possibility would be to make things case dependant (K = 1024 and k = 1000) or something like that. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: [ANNOUCE] iproute2 update
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 change all multipliers (for input as well as output) to 1000 or 1024? That way, nothing existing will be broken, and a warning should be placed in documentation that without -k flag, results are misleading. I'll leave the default selection for -k/-K up to you. Alternatively, (tc -k command) -alex ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] how flexible is ingress traffic policing to bandwidth limit?
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 most people setup the IMQ[1] device and you egress filters on it to control what is shaped and how. 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 use egress queues on the LAN interface. regards, -- ~~~ Damion de Soto - Software Engineer email: [EMAIL PROTECTED] SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliancesweb: http://www.snapgear.com ~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: [ANNOUCE] iproute2 update
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 10 000 000 bits/second. Someone who may be trying to rate-limit outbound traffic is bound for a surprise when tc's 10mbit does not match physical line characteristic. Other examples: 28k modem is 28000 bit/s, 56k is 56000, OC-3 SONET (155Mbit) is 15500 bit/s, etc. There isn't a technology that is quoted with kbits meaning 1024bit/s. -alex On Tue, 8 Jun 2004, Stephen Hemminger wrote: 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 intend this to build and run on 2.6 (and 2.4) only. * Fixed some parsing and formatting bugs. * Added gigabit as a rate. * Added HTB and delay scheduler * Added support for new tcp_info extensions to ss The website is: http://developer.osdl.org/dev/iproute2 and the download is in: http://developer.osdl.org/dev/iproute2/download This version builds with 2.6.7 as the kernel include files, so either have the files in /usr/include/linux up to date or modify the top level Makefile to point to a kernel build. Will workout a way to build on 2.4 next. - To unsubscribe from this list: send the line unsubscribe linux-net in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Is it possible to control uplink in a NATted environment
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, -- ~~~ Damion de Soto - Software Engineer email: [EMAIL PROTECTED] SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliancesweb: http://www.snapgear.com ~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?
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 use egress queues on the LAN interface. 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? IMQ does seem like a handy tool, but why is there a distinction at all between egress and ingress qdiscs at all? Why not just allow people to attach HTB as an ingress qdisc directly? I suppose in an ideal world the best thing would be to receive the packets, hand them to user-space, but not mark them as received, ie, not ack them. That avoids introducing any loss from the user point of view but still slows the flow down. But that seems fiddly and would only work for TCP I guess. -- greg ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?
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 egress qdiscs on your outbound (WAN) interface (to shape upload speeds) and want to filter based on private (LAN) IP address. IMQ does seem like a handy tool, but why is there a distinction at all between egress and ingress qdiscs at all? Why not just allow people to attach HTB as an ingress qdisc directly? because you can't shape inbound traffic. Shaping works by delaying the transmission, and you can't delay packets that haven't arrived yet. Ingress policing just drops packets, and hopes the sender will slow down. I suppose in an ideal world the best thing would be to receive the packets, hand them to user-space, but not mark them as received, ie, not ack them. That avoids introducing any loss from the user point of view but still slows the flow down. But that seems fiddly and would only work for TCP I guess. That's an interesting idea, but yeah... i think it might be a bit hard to implement, and violate far too many RFCs... regards, -- ~~~ Damion de Soto - Software Engineer email: [EMAIL PROTECTED] SnapGear - A CyberGuard Company ---ph: +61 7 3435 2809 | Custom Embedded Solutions fax: +61 7 3891 3630 | and Security Appliancesweb: http://www.snapgear.com ~~~ --- Free Embedded Linux Distro at http://www.snapgear.org --- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [ANNOUCE] iproute2 update
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 things case dependant (K = 1024 and k = 1000) or something like that. If 1024 is not used in real networks (I don't know) then you should just ditch it completely, IMO. Offering two possibilities is fine, but could also easily lead to even more confusion. Andreas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?
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 iptables to mark traffic, is when you're using egress qdiscs on your outbound (WAN) interface (to shape upload speeds) and want to filter based on private (LAN) IP address. Well I'll be doing the opposite here, putting an egress qdisc on my LAN interface limiting the downstream bandwidth. So I would have the equivalent need, to distinguish traffic originating from outside vs traffic originating from the router so I can still scp kernels over to the router without being limited. Hm, though in practice I hardly ever scp things _from_ the router so perhaps I don't care. IMQ does seem like a handy tool, but why is there a distinction at all between egress and ingress qdiscs at all? Why not just allow people to attach HTB as an ingress qdisc directly? because you can't shape inbound traffic. Shaping works by delaying the transmission, and you can't delay packets that haven't arrived yet. Ingress policing just drops packets, and hopes the sender will slow down. Well ultimately all shaping works by dropping packets. Merely delaying transmission isn't going to slow down anything in the long run, just increase the pipeline. You can delay and/or drop them after they've arrived just as easily. Though it would have to be before they're ack'd and delivered to the user. That's basically what IMQ does, I'm just saying perhaps that should just work instead of requiring a fake interface. Hm, I wonder if I want RED or something similar to ensure packets get dropped fast enough instead of filling HTB queues and then dropping. I suppose in an ideal world the best thing would be to receive the packets, hand them to user-space, but not mark them as received, ie, not ack them. That avoids introducing any loss from the user point of view but still slows the flow down. But that seems fiddly and would only work for TCP I guess. That's an interesting idea, but yeah... i think it might be a bit hard to implement, and violate far too many RFCs... My original thought was to just drop an ACK packet, which would clearly not violate any assumptions. But if there's data in the ACK packet that could have negative effects. I suspect this lies well into Bad Idea(tm) realm, I'm just thinking out loud. -- greg ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [ANNOUCE] iproute2 update
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] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] wondershaper under Debian
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! :) Fernando Favero - Original Message - From: Sebastian A. Aresca To: Fernando Favero Sent: Tuesday, June 08, 2004 1:45 AM Subject: Re: [LARTC] wondershaper under Debian Fernando: mira la verdad ni idea de lo que puede llegar a ser. Yo estoy usando un debian 3.0r1 con un kernel 2.4.26 compilado por mi (este ya trae htb3 ya patcheado) Pero el tema aca es que no creo que te vallan a responder en la lista ya que tu mail no es para nada explicativo. No se si serás nuevo en la lista, pero dudo a que te respondan. Más bien intentá juntar más información y talvez llegues a tu respuesta. Saludos Sebastián A. Aresca NTA - Area Redes UTN Rosario- Argentina http://www.frro.utn.edu.ar - Original Message - From: Fernando Favero To: [EMAIL PROTECTED] Sent: Monday, June 07, 2004 9:45 PM Subject: [LARTC] wondershaper under Debian Hi everybody! I know this discussion list isn´t just about wondershaper, but i think someone can help me. I used to have a linux box running red hat 8, as firewallon my lan. I upgraded to debian 3.0 and tried to use the same wondershaper files under debian, but, when i run wondershaper on ppp0 device, it just stops transfering. Remember: its the same files i used with success under red hat 8. The only difference in the connection between red hat 8 and debian 3 is that under rh8 i used rp-pppoe and under debian i use the default pppoe dialer. I don´t get any error message. What can be wrong? I am using: P166Mhz 32MB Ram debian 3.0 (only console) kernel 2.4.18 iptables v1.2.6a Tks in advance and sorry my english. Fernando Favero
