Re: [LARTC] 2 providers & DNAT: incoming packets not forwarded
If you have default policy in forward chain to DROP you must permit those packets to pass. Razvan Stranschi [EMAIL PROTECTED] Raphael Benedet wrote: Hi, I have a problem with incoming connections on my Linux gateway. I have 2 providers, cable modem on eth1 and dsl on eth2 <-> ppp0 (pppoe). The lan network is connected to eth0. At the moment, I have a very simple configuration where the default route is via eth1 (cable modem). I set up DNAT on ppp0 to forward incoming traffic for certain ports to a computer behind the gateway/firewall: iptables -t nat -A PREROUTING -i ppp0 -p tcp -m tcp --dport 2000 -j DNAT --to-destination 172.16.1.4 Packets get lost and never reach the FORWARD chain (I logged all packets to be sure) Here are my routes: # ip route ls 215.136.169.1 dev ppp0 proto kernel scope link src 215.136.169.15 135.165.199.128/25 dev eth1 proto kernel scope link src 135.165.199.139 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.1.1 default via 135.165.199.129 dev eth1 So, I understand traffic by default goes via eth1, but why don't incoming packets redirected (DNATed) to an intranet IP address go out via eth0? If I change my default route in table main to go via ppp0, then, it works. And DNATing on eth1 works with the current configuration. I don't have any other routing tables nor complex routing rules: # ip rule ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default I am running kernel 2.4.23 with Julian's patches. Any help would be greatly appreciated. Thank you. Raph --- This e-mail was scanned for viruses by ARVO. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Latency low enough for gaming
On Thu, 19 Feb 2004 09:45:16 +, Andy Furniss <[EMAIL PROTECTED]> wrote: > The delete rule for iptabled needs -D not -A. Yes, that one was bad. I noticed it when i discovered how to list rules in chains... I think all my rules was there about 10 times each, since i never removed anything :) > esfq won't work hashing src on egress if you are doing NAT see the KPTD > on www.docum.org - egress qos comes after NAT. Ingress with dst should > be ok if you are NATing as long as you used the IMQ NAT patch. I thought that with the NAT patch, imq would see incoming packets with the real ip on the internal net? > The trouble with esfq hashing per user (unless you use limit) is that > each user gets a 128 packet queue, which if they have many connections > gets full and drops take a long time to be noticed. I have a modified > esfq which overcomes this somewhat, but I also use classic hash and > restrict the size of the queue. I didnt thing a 128 packet queue would do any real difference, but im testing with other qdiscs at the moment, since it seems that bandwidth is being divided, but there is still latency problems. > I can see why commercial bandwidth controllers use advertised window > manipulation - often dropping is needed to get the sender to back off a > bit and set its' congestion window, but if you queue this may result in > a resync burst later. Being able to reduce adv window on dups/sacks and > increase slowly/randomly would be handy. Ah yes, the holy grail it seems. Its a mystery that noone has started an open source project for this. > One thing that helps me is to give new bulk connections their own class > with a short queue for the first 8 bytes using connbytes (netfilter > extra patch). This is limited to rate downrate/5 ceil /3 and stops tcp > slowstart from overshooting. I have also tried connbytes just to drop > early packets, but with browsers making many simultaneous connections, > the resyncs cause a latency burst. If im getting this right, you are using iptables to manage bandwidth directly? Im real bad with iptables still, i dont think ive gotten to know half of it yet. > I see you are trying RED - in theory this should be nice, but remember > the settings/docs you read about don't take into account that you are > trying to shape behind a fifo (at ISP/teleco) that dequeues only 20% > faster than what you are aiming for. Im still kind of blank on RED, what im trying out now is to use the RED part of Jim diGriz' (i think) script. It seems that a few packets are actually dropped when the link is getting full, but only about 5-10 in a couple of minutes.. Seems a bit low? > I am not convinced that just dropping ingress is best - a short queue > yes, then at least you don't ever drop game packets. This is what im trying to do now, using IMQ for incoming traffic. However, it seems that my 2 root qdiscs are delaying packets a lot. According to tc -s qdisc etc etc about 100-500 packets are overlimits, even when dataflow is no more than around 5-10kb/s. Setting a ceil on the root classes seems to help it out a little, but not completely. This i dont understand. -- Patrick Petersen <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] HTB Quatum values
Hi guys, I've just been playing and reading again, and come to the conclusion that although i've read a lot about quantum (& r2q) settings for the htb qdisc, i still don't understand it. If the quantum for each class should be as small as possible, but larger than the MTU, then is there any reason I shouldn't always set it to the MTU size ? If 2 classes are fulfulling their rate and you want them to share unequally, instead of making the quantums different of each one, why not just change the prio ? 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] HTB files ???
Hi Thank you very much for the replies. I've heared that tc rules can be directly executed for each class (Please correct me if I'm wrong) instead of creating the HTB files in /etc/sysconfig/htb/. Which method is preferable. Right now I'm doing QoS for a pool of 254 IP's, for which I've written separate 254 class files in /etc/sysconfig/htb, including the interface (eth0) and root class. Is this the right method ? If I can move ahead with the same setup, and create files for 3000 IP's will there be any sort of issues. Please suggest me. Thank you regards Vinoos. On Thu, 19 Feb 2004 19:40:54 +0100 Stef Coene <[EMAIL PROTECTED]> wrote: > On Monday 16 February 2004 12:12, Vinu Chandran wrote: > > Hi all > > I would like to implement QoS using the HTB utility. My network might get > > increased to around 3000 clients. I would like to know is there any > > limitation in using HTB for a network like this ? Can I move ahead in > > configuring the same ? Is there any other similar possible methods thru > > which I can achieve this ? I need to assign shared and dedicated bandwidth > > to our customers. > Most of the limitations are related to the active classes and flows in the > network. Fast CPU and enough memory will help. > > > Can I do Qos (shared and dedicated) for individual (3000 approx.) IP's > > separately ? > Yes. > > > Will there be any performance issues in real time ? > Yes, each device in the network gives a delay. But I don't think you will > notice the extra delays. > > Stef > > -- > [EMAIL PROTECTED] > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net > ___ > 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/
[LARTC] Split Routing
Dear All, Can ip tools and netfilter deal with my routing problem here : 192.168.0.0/24 --- | || (eth1) 203.158.254.2/24 -- 203.158.254.1 /24(e0) |-| |-19216.80.225(eth0)| RH-9.0 | | Cisco | --internet 192.168.0.231 --- | | ---|(eth1:2) 203.158.252.236/30 ---203.158.252.237/30(e0.1)| | Default gateway to internetfrom RH-9.0 to internet is 202.158.254.1. how can i make routing decision from 203.158.252.236 (virtual interface) to internet via 203.158.252.237 ? I want do SNAT from 203.138.252.236 to 192.168.0.231,and make routing decision for outgoing 192.168.0.231 to internet via 203.138.252.236. Is that possible ?, please help me. regards reza ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How about libtc
> > > or implement file parsing like iptables-restore > > iptables-restore does not parse the iptables input, > it talks directly to the kernel. > I was talking about other thing, iptables-restore can take multiple lines at once while iptables can parse one line at one run only of course it does not call iptables ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final !
>> Roy, >> '"'But this stability is probably not because my code is better but because >> I don't use egress shaping so the crash reasons still unknown.'"' >> >I need both ingress and egress traffic shaping, that's why I used the >classic IMQ version. Egress shaping will crash original wersion even faster then mine, they both can do this , but then both will likely crash anyway you can do egress shaping on interface directly, and input+forward on imq device. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final !
Roy, "But this stability is probably not because my code is better but because I don't use egress shaping so the crash reasons still unknown." I need both ingress and egress traffic shaping, that's why I used the classic IMQ version. > You can try my imq version, which dows not require paching anything > > http://pupa.da.ru/imq > and I think it should be more stable. > > > > > > Hi, > > I have successfully applied the IMQ patch for kernel-2.6.2 (final > > release) from http://www.linuximq.net, and now I have support for 4 IMQ > > devices loaded in kernel. But I don't know how to patch the iptables-1.2.9 > > to support the -j IMQ target. I tried the patch-o-matic for 2.4.x kernels, > > but it doesn't work for 2.6.x kernels. I also tried the patch-o-matic-ng > > for 2.6.x kernels, but when I give the batch script commands it says it's > > not implemented yet. I don't know how to manually apply the IMQ patches. > > > > ./runme --batch userspace/IMQ.patch > > > > Could anyone help me how to do this final step and append IMQ support to > > iptables? > > > > -- > - > > > > Hi again. > > I manually patched in the iptables-1.2.9/extensions directory, the files: > > .IMQ-test > > .IMQ-test6 > > libip6t-IMQ.c > > libipt-IMQ.c > > from the pom-20030625.diff file, and it passed. Now I have the imq devices > > up and running with kernel-2.6.2, but there is another problem: when I use > > iptables . -j IMQ I got Segmentation fault, and dmesg says: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > 0001 > > printing eip: > > c0372908 > > *pde = 18ddc067 > > Oops: [#1] > > CPU:0 > > EIP:0060:[]Not tainted > > EFLAGS: 00010202 > > EIP is at imq_target+0x8/0x30 > > eax: 0001 ebx: c045f820 ecx: d8db7c04 edx: c045f820 > > esi: e08170f0 edi: e0817080 ebp: 0001 esp: d8db7b64 > > ds: 007b es: 007b ss: 0068 > > Process iptables (pid: 1648, threadinfo=d8db6000 task=d9e69900) > > Stack: c03695ee d8db7c04 e0817080 e0817110 0004 0001 e0817080 > > d8db7ba8 > >d8db6000 deff9420 deff9480 0070 > > 0163 > > > > > > Call Trace: > > [] translate_table+0x4be/0x760 > > [] do_replace+0x193/0x6e0 > > [] vfree+0x27/0x40 > > [] do_ipt_set_ctl+0x6d/0x70 > > [] nf_sockopt+0x12f/0x140 > > [] nf_setsockopt+0x37/0x40 > > [] ip_setsockopt+0x4a7/0xd90 > > [] nf_sockopt+0xb4/0x140 > > [] nf_getsockopt+0x37/0x40 > > [] ip_getsockopt+0x681/0x7c0 > > [] journal_stop+0x201/0x360 > > [] ext3_mark_iloc_dirty+0x28/0x40 > > [] ext3_mark_inode_dirty+0x50/0x60 > > [] __ext3_journal_stop+0x24/0x50 > > [] ext3_dirty_inode+0x69/0xd0 > > [] __mark_inode_dirty+0xde/0xf0 > > [] buffered_rmqueue+0xd1/0x170 > > [] buffered_rmqueue+0xd1/0x170 > > [] __alloc_pages+0x9f/0x330 > > [] __alloc_pages+0x9f/0x330 > > [] find_get_page+0x2c/0x60 > > [] do_anonymous_page+0x17a/0x260 > > [] do_no_page+0x65/0x3a0 > > [] pte_alloc_map+0x9b/0xc0 > > [] handle_mm_fault+0xd4/0x180 > > [] do_page_fault+0x2fc/0x4dc > > [] inet_setsockopt+0x36/0x40 > > [] sys_setsockopt+0x82/0xd0 > > [] sys_socketcall+0x220/0x2a0 > > [] sysenter_past_esp+0x52/0x71 > > > > Code: 0f b6 00 8b 11 83 c8 80 88 82 94 00 00 00 8b 01 81 88 84 00 > > > > > > Does anybody know why it crashes and how can I handle this mess ? > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final !
You can try my imq version, which dows not require paching anything http://pupa.da.ru/imq and I think it should be more stable. - Original Message - From: "The Codrinus" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 19, 2004 6:19 PM Subject: [LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final ! > > > Hi, > I have successfully applied the IMQ patch for kernel-2.6.2 (final > release) from http://www.linuximq.net, and now I have support for 4 IMQ > devices loaded in kernel. But I don't know how to patch the iptables-1.2.9 > to support the -j IMQ target. I tried the patch-o-matic for 2.4.x kernels, > but it doesn't work for 2.6.x kernels. I also tried the patch-o-matic-ng > for 2.6.x kernels, but when I give the batch script commands it says it's > not implemented yet. I don't know how to manually apply the IMQ patches. > > ./runme --batch userspace/IMQ.patch > > Could anyone help me how to do this final step and append IMQ support to > iptables? > > -- - > > Hi again. > I manually patched in the iptables-1.2.9/extensions directory, the files: > .IMQ-test > .IMQ-test6 > libip6t-IMQ.c > libipt-IMQ.c > from the pom-20030625.diff file, and it passed. Now I have the imq devices > up and running with kernel-2.6.2, but there is another problem: when I use > iptables . -j IMQ I got Segmentation fault, and dmesg says: > > Unable to handle kernel NULL pointer dereference at virtual address > 0001 > printing eip: > c0372908 > *pde = 18ddc067 > Oops: [#1] > CPU:0 > EIP:0060:[]Not tainted > EFLAGS: 00010202 > EIP is at imq_target+0x8/0x30 > eax: 0001 ebx: c045f820 ecx: d8db7c04 edx: c045f820 > esi: e08170f0 edi: e0817080 ebp: 0001 esp: d8db7b64 > ds: 007b es: 007b ss: 0068 > Process iptables (pid: 1648, threadinfo=d8db6000 task=d9e69900) > Stack: c03695ee d8db7c04 e0817080 e0817110 0004 0001 e0817080 > d8db7ba8 >d8db6000 deff9420 deff9480 0070 > 0163 > > > Call Trace: > [] translate_table+0x4be/0x760 > [] do_replace+0x193/0x6e0 > [] vfree+0x27/0x40 > [] do_ipt_set_ctl+0x6d/0x70 > [] nf_sockopt+0x12f/0x140 > [] nf_setsockopt+0x37/0x40 > [] ip_setsockopt+0x4a7/0xd90 > [] nf_sockopt+0xb4/0x140 > [] nf_getsockopt+0x37/0x40 > [] ip_getsockopt+0x681/0x7c0 > [] journal_stop+0x201/0x360 > [] ext3_mark_iloc_dirty+0x28/0x40 > [] ext3_mark_inode_dirty+0x50/0x60 > [] __ext3_journal_stop+0x24/0x50 > [] ext3_dirty_inode+0x69/0xd0 > [] __mark_inode_dirty+0xde/0xf0 > [] buffered_rmqueue+0xd1/0x170 > [] buffered_rmqueue+0xd1/0x170 > [] __alloc_pages+0x9f/0x330 > [] __alloc_pages+0x9f/0x330 > [] find_get_page+0x2c/0x60 > [] do_anonymous_page+0x17a/0x260 > [] do_no_page+0x65/0x3a0 > [] pte_alloc_map+0x9b/0xc0 > [] handle_mm_fault+0xd4/0x180 > [] do_page_fault+0x2fc/0x4dc > [] inet_setsockopt+0x36/0x40 > [] sys_setsockopt+0x82/0xd0 > [] sys_socketcall+0x220/0x2a0 > [] sysenter_past_esp+0x52/0x71 > > Code: 0f b6 00 8b 11 83 c8 80 88 82 94 00 00 00 8b 01 81 88 84 00 > > > Does anybody know why it crashes and how can I handle this mess ? > > thank you, > Codrin. > ___ > 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] VSAT sysctl parameters
hi andres, i re-read your question and now that i have a bit more time, i'll try to respond to it more carefully: On Fri, 2004-02-13 at 21:37, ThE LinuX_KiD wrote: > Hi, > > I'm trying to setting a very low bandwidth > VSAT connection (90 kbits download / 20kbits upload) > > I'm looking for best kernel SYSCTL parameters for this > > Have someone a sysctl configuration for this ? your question implies that the vsat system that you're currently using is un-optimized by the provider -- i'll try to explain. here in europe, the two principal providers Eutelsat and Satlynx both offer true two-way satellite service that are asymmetrical in bandwidth. the eutelsat d-start product as well as the satlynx 360e are both optimized by the provider, that is to say, that both re-negotiate the layer 4 tcp connection parameters for each tcp session. if you take the time to try to reset the tcp parameters, it is really unnecessary as they are thrown out and replaced by the providers variables (performed by the indoor unit). the exceptions are the astra bbi platform and other "pure" vsat platforms that do not perform layer 4 renegotiation or ack spoofing and the like. at this point, tweaking the sysctl parameters helps enormously, however, it is noteworthy that a client passing its traffic via your linux router, will not inherit the router's parameters: each client will setup its own tcp parameters during the handshake. so, here's a brief summary: squid and/or another http proxy: a http proxy server is recommended in all cases. setup a large cache, good memory and cache object size. avoid using the bandwidth if you do not have to. satlynx 360e: no need to much here with your router, excepting that you should really try to make use of the http proxy port (9877) provided by the indoor unit. you can setup a transparent squid proxy (or regular) and put a line in the squid.conf like: cache_peer $GILAT_INDOOR_IP parent 9877 0 no-query when squid doesn't find the cache object, it will send the http request through their proxy port and you will enjoy the benefits of their caching and acceleration. eutelsat d-star: like the gilat, eutelsat has optimized their backbone with ack spoofing and tcp layer renegotiation. no need to worry about clients behind this idu either. astra bbi and other "pure" vsat connections: here you will want to do your maximum effort to tweak sysctl and use a proxy so that the linux router will use its tcp paramters at layer 4. here's a few suggestions for sysctl.conf, your mileage may vary: net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.ipv4.tcp_wmem = 4096 20 25 net.ipv4.tcp_rmem = 4096 20 25 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_fack = 1 #net.ipv4.tcp_wmem = 4096 87380 4194304 #net.ipv4.tcp_wmem = 4096 25 30 #net.ipv4.tcp_rmem = 4096 87380 4194304 #net.ipv4.tcp_rmem = 4096 15 20 the # statements were taken from several howtos and you should give them a try to see if your getting improvements. remember again that using squid will cause these parameters to be used as opposed to a client behind that does its own layer 4 negotiation. iptables patches may be of help as well to get a clients tcp negotiation to support better congestion window size. older ip stacks (i.e. win 95 and nt 40) can be problematic as these paramters cannot be changed (as far as i know). patience, testing, and let us know! cheers charles ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Traffic priority by mark
Hi all, Short(and hopefully simple) question, What is the simplest way to prioritize traffic by a mark set erlier with l7-filter. no bandwidthlimiting, just prio to packets with a low mark(using 1- 8) Regards //Magnus
Re: [LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final !
> On Thursday 19 February 2004 17:19, The Codrinus wrote:
> > Hi,
> > I have successfully applied the IMQ patch for kernel-2.6.2 (final
> > release) from http://www.linuximq.net, and now I have support for 4 IMQ
> > devices loaded in kernel. But I don't know how to patch the iptables-1.2.9
> > to support the -j IMQ target. I tried the patch-o-matic for 2.4.x kernels,
> > but it doesn't work for 2.6.x kernels. I also tried the patch-o-matic-ng
> > for 2.6.x kernels, but when I give the batch script commands it says it's
> > not implemented yet. I don't know how to manually apply the IMQ patches.
> >
> > ./runme --batch userspace/IMQ.patch
> >
> > Could anyone help me how to do this final step and append IMQ support to
> > iptables?
> I'm not sure, but I think you don't need iptables for the latest imq. All
> traffic is also flowing thru the imq devices. But I'm not sure.
>
> Stef
>
Well, iptables need in the extensions dir the following IMQ patch files:
".IMQ-test"
".IMQ-test6"
"libipt_IMQ.c" and
"libip6t_IMQ.c"
in order to support the -j IMQ --todev option.
I manually added these files because the patch-o-matic-ng doesn't know how
to apply --batch option. (not implemented yet)
The problem is after all, when I try to give an iptables command like:
iptables -j IMQ --todev eth0 when running the patched kernel-2.6.2
i get segmentation fault and dmesg says the following coredump error:
Unable to handle kernel NULL pointer dereference at virtual address
0001
printing eip:
c0372908
*pde = 18ddc067
Oops: [#1]
CPU:0
EIP:0060:[]Not tainted
EFLAGS: 00010202
EIP is at imq_target+0x8/0x30
eax: 0001 ebx: c045f820 ecx: d8db7c04 edx: c045f820
esi: e08170f0 edi: e0817080 ebp: 0001 esp: d8db7b64
ds: 007b es: 007b ss: 0068
Process iptables (pid: 1648, threadinfo=d8db6000 task=d9e69900)
Stack: c03695ee d8db7c04 e0817080 e0817110 0004 0001 e0817080
d8db7ba8
d8db6000 deff9420 deff9480 0070
0163
Call Trace:
[] translate_table+0x4be/0x760
[] do_replace+0x193/0x6e0
[] vfree+0x27/0x40
[] do_ipt_set_ctl+0x6d/0x70
[] nf_sockopt+0x12f/0x140
[] nf_setsockopt+0x37/0x40
[] ip_setsockopt+0x4a7/0xd90
[] nf_sockopt+0xb4/0x140
[] nf_getsockopt+0x37/0x40
[] ip_getsockopt+0x681/0x7c0
[] journal_stop+0x201/0x360
[] ext3_mark_iloc_dirty+0x28/0x40
[] ext3_mark_inode_dirty+0x50/0x60
[] __ext3_journal_stop+0x24/0x50
[] ext3_dirty_inode+0x69/0xd0
[] __mark_inode_dirty+0xde/0xf0
[] buffered_rmqueue+0xd1/0x170
[] buffered_rmqueue+0xd1/0x170
[] __alloc_pages+0x9f/0x330
[] __alloc_pages+0x9f/0x330
[] find_get_page+0x2c/0x60
[] do_anonymous_page+0x17a/0x260
[] do_no_page+0x65/0x3a0
[] pte_alloc_map+0x9b/0xc0
[] handle_mm_fault+0xd4/0x180
[] do_page_fault+0x2fc/0x4dc
[] inet_setsockopt+0x36/0x40
[] sys_setsockopt+0x82/0xd0
[] sys_socketcall+0x220/0x2a0
[] sysenter_past_esp+0x52/0x71
Code: 0f b6 00 8b 11 83 c8 80 88 82 94 00 00 00 8b 01 81 88 84 00
I really don't know why it crashes and how can I handle this mess,
Codrin.
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final !
On Thursday 19 February 2004 17:19, The Codrinus wrote: > Hi, > I have successfully applied the IMQ patch for kernel-2.6.2 (final > release) from http://www.linuximq.net, and now I have support for 4 IMQ > devices loaded in kernel. But I don't know how to patch the iptables-1.2.9 > to support the -j IMQ target. I tried the patch-o-matic for 2.4.x kernels, > but it doesn't work for 2.6.x kernels. I also tried the patch-o-matic-ng > for 2.6.x kernels, but when I give the batch script commands it says it's > not implemented yet. I don't know how to manually apply the IMQ patches. > > ./runme --batch userspace/IMQ.patch > > Could anyone help me how to do this final step and append IMQ support to > iptables? I'm not sure, but I think you don't need iptables for the latest imq. All traffic is also flowing thru the imq devices. But I'm not sure. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB limitations if any
On Monday 16 February 2004 12:12, Vinu Chandran wrote: > Hi all > I would like to implement QoS using the HTB utility. My network might get > increased to around 3000 clients. I would like to know is there any > limitation in using HTB for a network like this ? Can I move ahead in > configuring the same ? Is there any other similar possible methods thru > which I can achieve this ? I need to assign shared and dedicated bandwidth > to our customers. Most of the limitations are related to the active classes and flows in the network. Fast CPU and enough memory will help. > Can I do Qos (shared and dedicated) for individual (3000 approx.) IP's > separately ? Yes. > Will there be any performance issues in real time ? Yes, each device in the network gives a delay. But I don't think you will notice the extra delays. Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc and u32 and filter documentation !
On Monday 16 February 2004 13:42, Rhaoni - Sistêmica wrote: > Hi List, > >Considering this QoS scenario: > >tc qdisc add dev eth0 root handle 1: htb default 12 >tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit ceil > 100kbps tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbit ceil > 100kbps tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbit ceil > 100kbps tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbit ceil > 100kbps tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ > match ip src 1.2.3.4 match ip dport 80 0x flowid 1:10 >tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ > match ip src 1.2.3.4 flowid 1:11 >tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ > match ip dport 80 0x flowid 1:10 > >Here follows my doubts: > >Where will be classified a packet coming from 1.2.3.4 port 80 ? 1:10. > ( just to be sure 'cuz I'm making a very simple QoS tutorial in portuguese > brazilian ) > >Where ca I find a full tc syntax ( I already have the manpage ) and u32 > filter documentation ? Most of the options depends on what you do with the tc command: adding filters, qdiscs, classes, ... Stef -- [EMAIL PROTECTED] "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 2 providers & DNAT: incoming packets not forwarded
Hi, It is of course set to 1. I already have DNATing on eth1 and it works very well. I suppose my problem come from my routing table but I don't understand why no route is found to 172.16.1.4 coming from ppp0 with the current configuration. Regards, Raph Alexander A. Naumov wrote: Hi! May be you need to set /proc/sys/net/ipv4/ip_forward sysctl value to 1? Best regards, Alexander A. Naumov On Thu, Feb 19, 2004 at 03:45:06PM +0100, Raphael Benedet wrote: Hi, I have a problem with incoming connections on my Linux gateway. I have 2 providers, cable modem on eth1 and dsl on eth2 <-> ppp0 (pppoe). The lan network is connected to eth0. At the moment, I have a very simple configuration where the default route is via eth1 (cable modem). I set up DNAT on ppp0 to forward incoming traffic for certain ports to a computer behind the gateway/firewall: iptables -t nat -A PREROUTING -i ppp0 -p tcp -m tcp --dport 2000 -j DNAT --to-destination 172.16.1.4 Packets get lost and never reach the FORWARD chain (I logged all packets to be sure) Here are my routes: # ip route ls 215.136.169.1 dev ppp0 proto kernel scope link src 215.136.169.15 135.165.199.128/25 dev eth1 proto kernel scope link src 135.165.199.139 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.1.1 default via 135.165.199.129 dev eth1 So, I understand traffic by default goes via eth1, but why don't incoming packets redirected (DNATed) to an intranet IP address go out via eth0? If I change my default route in table main to go via ppp0, then, it works. And DNATing on eth1 works with the current configuration. I don't have any other routing tables nor complex routing rules: # ip rule ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default I am running kernel 2.4.23 with Julian's patches. Any help would be greatly appreciated. Thank you. Raph -- Raphael Benedet 3D Artists - raph.com "bringing art into the third dimension" ___ 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/
[LARTC] Force Packets onto Wire
Greetings, I'm trying to use a single Linux box to test a router. The Linux box has multiple ethernet cards in different subnets. When trying to send from one subnet to the other, Linux of course bypasses the external network. This doesn't test the router much! I'm looking for a way to force the packets out one NIC, through the router, and back in the other NIC. Ideally, I'd still like to use regular commands (ping, ttcp), and not have to create my own packets. While searching the web, I see this had been addressed in kernel 2.0 with a change by Brian Moyle to arp.c (which Alan Cox thought was unwise to adopt for the general distribution). I was wondering if anything similar has been done in the 2.4 code. Or can I use the advanced routing features and somehow coax Linux (e.g. via different TOS) that for some/all traffic, the external interface is better. I've played around with the "ip route" and "ip rule" commands, but don't yet have a sufficient understanding of the routing internals to do what I want. Any assistance in this area would be appreciated. Thanks, Tony
Re: [LARTC] 2 providers & DNAT: incoming packets not forwarded
Hi! May be you need to set /proc/sys/net/ipv4/ip_forward sysctl value to 1? Best regards, Alexander A. Naumov On Thu, Feb 19, 2004 at 03:45:06PM +0100, Raphael Benedet wrote: > Hi, > > I have a problem with incoming connections on my Linux gateway. > I have 2 providers, cable modem on eth1 and dsl on eth2 <-> ppp0 > (pppoe). The lan network is connected to eth0. At the moment, I have a > very simple configuration where the default route is via eth1 (cable > modem). I set up DNAT on ppp0 to forward incoming traffic for certain > ports to a computer behind the gateway/firewall: > iptables -t nat -A PREROUTING -i ppp0 -p tcp -m tcp --dport 2000 -j DNAT > --to-destination 172.16.1.4 > Packets get lost and never reach the FORWARD chain (I logged all packets > to be sure) > > Here are my routes: > > # ip route ls > 215.136.169.1 dev ppp0 proto kernel scope link src 215.136.169.15 > 135.165.199.128/25 dev eth1 proto kernel scope link src 135.165.199.139 > 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.1.1 > default via 135.165.199.129 dev eth1 > > So, I understand traffic by default goes via eth1, but why don't > incoming packets redirected (DNATed) to an intranet IP address go out > via eth0? > If I change my default route in table main to go via ppp0, then, it > works. And DNATing on eth1 works with the current configuration. > > I don't have any other routing tables nor complex routing rules: > # ip rule ls > 0: from all lookup local > 32766: from all lookup main > 32767: from all lookup default > > I am running kernel 2.4.23 with Julian's patches. > > Any help would be greatly appreciated. Thank you. > > Raph > > > -- > > Raphael Benedet > 3D Artists - raph.com > "bringing art into the third dimension" > > ___ > 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/
[LARTC] IMQ patch for iptables-1.2.9 and kernel 2.6.2 final !
Hi,
I have successfully applied the IMQ patch for kernel-2.6.2 (final
release) from http://www.linuximq.net, and now I have support for 4 IMQ
devices loaded in kernel. But I don't know how to patch the iptables-1.2.9
to support the -j IMQ target. I tried the patch-o-matic for 2.4.x kernels,
but it doesn't work for 2.6.x kernels. I also tried the patch-o-matic-ng
for 2.6.x kernels, but when I give the batch script commands it says it's
not implemented yet. I don't know how to manually apply the IMQ patches.
./runme --batch userspace/IMQ.patch
Could anyone help me how to do this final step and append IMQ support to
iptables?
---
Hi again.
I manually patched in the iptables-1.2.9/extensions directory, the files:
.IMQ-test
.IMQ-test6
libip6t-IMQ.c
libipt-IMQ.c
from the pom-20030625.diff file, and it passed. Now I have the imq devices
up and running with kernel-2.6.2, but there is another problem: when I use
iptables . -j IMQ I got Segmentation fault, and dmesg says:
Unable to handle kernel NULL pointer dereference at virtual address
0001
printing eip:
c0372908
*pde = 18ddc067
Oops: [#1]
CPU:0
EIP:0060:[]Not tainted
EFLAGS: 00010202
EIP is at imq_target+0x8/0x30
eax: 0001 ebx: c045f820 ecx: d8db7c04 edx: c045f820
esi: e08170f0 edi: e0817080 ebp: 0001 esp: d8db7b64
ds: 007b es: 007b ss: 0068
Process iptables (pid: 1648, threadinfo=d8db6000 task=d9e69900)
Stack: c03695ee d8db7c04 e0817080 e0817110 0004 0001 e0817080
d8db7ba8
d8db6000 deff9420 deff9480 0070
0163
Call Trace:
[] translate_table+0x4be/0x760
[] do_replace+0x193/0x6e0
[] vfree+0x27/0x40
[] do_ipt_set_ctl+0x6d/0x70
[] nf_sockopt+0x12f/0x140
[] nf_setsockopt+0x37/0x40
[] ip_setsockopt+0x4a7/0xd90
[] nf_sockopt+0xb4/0x140
[] nf_getsockopt+0x37/0x40
[] ip_getsockopt+0x681/0x7c0
[] journal_stop+0x201/0x360
[] ext3_mark_iloc_dirty+0x28/0x40
[] ext3_mark_inode_dirty+0x50/0x60
[] __ext3_journal_stop+0x24/0x50
[] ext3_dirty_inode+0x69/0xd0
[] __mark_inode_dirty+0xde/0xf0
[] buffered_rmqueue+0xd1/0x170
[] buffered_rmqueue+0xd1/0x170
[] __alloc_pages+0x9f/0x330
[] __alloc_pages+0x9f/0x330
[] find_get_page+0x2c/0x60
[] do_anonymous_page+0x17a/0x260
[] do_no_page+0x65/0x3a0
[] pte_alloc_map+0x9b/0xc0
[] handle_mm_fault+0xd4/0x180
[] do_page_fault+0x2fc/0x4dc
[] inet_setsockopt+0x36/0x40
[] sys_setsockopt+0x82/0xd0
[] sys_socketcall+0x220/0x2a0
[] sysenter_past_esp+0x52/0x71
Code: 0f b6 00 8b 11 83 c8 80 88 82 94 00 00 00 8b 01 81 88 84 00
Does anybody know why it crashes and how can I handle this mess ?
thank you,
Codrin.
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Load Balancing with compile redhat 8 vs Kudzu
Hello I got a nice problem, i don't know if the i'm put my question a the right place, but anyway I have 3 server LINUX with LVS (linux virtual server) I had to recompile my kernel cuz it was not supporting LVS. Since there, everything was going right. Then I've change the hard drive of the primairy LVS to an other computer, now i want KUDZU to detect my harware, but it doesn't do anythingIf i boot with the kernel not recompile, KUDZU work, but otherwise in KERNEL for LVS kudzu don't start and now messages, it just do nothing. Thx ! (sorry for my english ! It's not very good) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re:[LARTC] redhat 9 and htb
Hi, Try this: tc qdisc add dev eth0 root handle 1: htb default 12 []'s Anderson > Hi everyone, > > I have RH9 2.4.20-28.0 with iproute-2.4.7-7.90.1 installed. > But when I try > > tc qdisc add dev eth0 root handle 1:0 htb default 12 > Unknown qdisc "htb", hence option "default" is unparsable. > > There are some others settings that must be done in kernel? > > I search the archive but I saw that some people with same versions of > rh9 and iproute don't get this errors > > > Thank you :) > -- > > Razvan Stranschi > [EMAIL PROTECTED] > --- This e-mail was scanned for viruses by > ARVO. ___ LARTC mailing list / > [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > http://lartc.org/ > __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] 2 providers & DNAT: incoming packets not forwarded
Hi, I have a problem with incoming connections on my Linux gateway. I have 2 providers, cable modem on eth1 and dsl on eth2 <-> ppp0 (pppoe). The lan network is connected to eth0. At the moment, I have a very simple configuration where the default route is via eth1 (cable modem). I set up DNAT on ppp0 to forward incoming traffic for certain ports to a computer behind the gateway/firewall: iptables -t nat -A PREROUTING -i ppp0 -p tcp -m tcp --dport 2000 -j DNAT --to-destination 172.16.1.4 Packets get lost and never reach the FORWARD chain (I logged all packets to be sure) Here are my routes: # ip route ls 215.136.169.1 dev ppp0 proto kernel scope link src 215.136.169.15 135.165.199.128/25 dev eth1 proto kernel scope link src 135.165.199.139 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.1.1 default via 135.165.199.129 dev eth1 So, I understand traffic by default goes via eth1, but why don't incoming packets redirected (DNATed) to an intranet IP address go out via eth0? If I change my default route in table main to go via ppp0, then, it works. And DNATing on eth1 works with the current configuration. I don't have any other routing tables nor complex routing rules: # ip rule ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default I am running kernel 2.4.23 with Julian's patches. Any help would be greatly appreciated. Thank you. Raph -- Raphael Benedet 3D Artists - raph.com "bringing art into the third dimension" ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] redhat 9 and htb
I solved the problem, I install iproute-2.4.7-7.11 from Fedora, I find this ideea on this list somewhere, now it works :) Thanks for suggestions Razvan Stranschi [EMAIL PROTECTED] Razvan Stranschi wrote: Hi everyone, I have RH9 2.4.20-28.0 with iproute-2.4.7-7.90.1 installed. But when I try tc qdisc add dev eth0 root handle 1:0 htb default 12 Unknown qdisc "htb", hence option "default" is unparsable. There are some others settings that must be done in kernel? I search the archive but I saw that some people with same versions of rh9 and iproute don't get this errors Thank you :) -- Razvan Stranschi [EMAIL PROTECTED] --- This e-mail was scanned for viruses by ARVO. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- This e-mail was scanned for viruses by ARVO. --- This e-mail was scanned for viruses by ARVO. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] redhat 9 and htb
Razvan Stranschi wrote: tc qdisc add dev eth0 root handle 1:0 htb default 12 Unknown qdisc "htb", hence option "default" is unparsable. There are some others settings that must be done in kernel? There's a chance you don't have the htb kernel module installed on your box. I'm not sure if it's included on a default RH9 installation. When you do an lsmod you should see a module sch_htb listed. If not you'll probably have to recompile a newer kernel and include support for HTB (I believe it's under QOS in the networking options section). Hope that helps - good luck! -- Chad Juettner [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] HTB and SNAT
I want an advise, because I don't know much about lartc, I am using htb.init. What I want to accomplish: I have a RH9 as gateway in a network with 30 computers. RH9 make SNAT for them to go out on internet, and I want to be able to assign different bandwidth to different computer in local network. 192.168.0.2 | | | | 192.168.0.3 | switch | --->eth0 | RedHat 9 | eth1 -> internet .. | | | | |__ _| || If I understand corectly I must: 1. include both eth0 and eth1 in traffic control: eth0 will limit download and eth1 will limit upload from lan host perspective 2. because on eth1 I make SNAT I cannot differentiate by source IP different classes, all packets will have the public IP as source after SNAT so I must MARK packets and different classes by this MARK Are any other issue to take in account here? Thank you. -- Razvan Stranschi [EMAIL PROTECTED] --- This e-mail was scanned for viruses by ARVO. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] redhat 9 and htb
I want an advise, because I don't know much about lartc, I am using htb.init. What I want to accomplish: I have a RH9 as gateway in a network with 30 computers. RH9 make SNAT for them to go out on internet, and I want to be able to assign different bandwidth to different computer in local network. 192.168.0.2 | | | | 192.168.0.3 | switch | --->eth0 | RedHat 9 | eth1 -> internet .. | | | | |__ _| || If I understand corectly I must: 1. include both eth0 and eth1 in traffic control: eth0 will limit download and eth1 will limit upload from lan host perspective 2. because on eth1 I make SNAT I cannot differentiate by source IP different classes, all packets will have the public IP as source after SNAT so I must MARK packets and different classes by this MARK Are any other issue to take in account here? Thank you. -- Razvan Stranschi [EMAIL PROTECTED] --- This e-mail was scanned for viruses by ARVO. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] test
test ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] IMQ and ISDN?
Hi, has anyone IMQ device running on an ISDN line for incoming shaping? I tried to but everytime a packet gets from the ippp0 to imq0 the kernel crashes. Does this work somewhere? thx 4 help cord ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] VSAT sysctl parameters
Hi Andres, Can you specify which satellite platform your on? Gilat/Satlynx, Eutelsat, Astra BBI -- they each have some differences ... Cheers Charles On Fri, 2004-02-13 at 21:37, ThE LinuX_KiD wrote: > Hi, > > I'm trying to setting a very low bandwidth > VSAT connection (90 kbits download / 20kbits upload) > > I'm looking for best kernel SYSCTL parameters for this > > Have someone a sysctl configuration for this ? > > Thank you! > andres > ___ > 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] Re: Latency low enough for gaming
Hi, Can i have more abt Random Early Drop (RED) mechanism. Help me with reference sites, sample codings, etc. I am in the process of shaping the bandwidth, in which i like to know how i can drop the packets when it exceeds the specified limit. Kindly help me with reference sites, sample codings, etc., Thanks & Regards, Kalaiselvan. > Patrick Petersen wrote: > > I have learned a lot from the lartc list archive, but this specifik > > leaves me with no clue. I have been able to get real close to normal > > latency by capping incoming traffic at around 1200kbits, but its no > > fun throwing away almost half your bandwidth. > > > > Can i get any recommendations? > > Let's get the problem statement clear first. > > First of all, it is obvious that the high latency is a result of > queueing at the ISP, before the packets are send over the slow link > to your router. ISPs have very long queues normally. > > Secondly, one needs to understand that there isn't really a damn > thing you can do about it. If someone ping-floods you, it will > saturate your downlink and latency will go through the roof. This > cannot be prevented except by having access to your ISP. > > And thirdly, the only thing you can do, is to either discard or > delay perfectly good packets which have already travelled over your > slow link and spent bandwidth on it. If you drop a packet, it will > most likely have to be resent and again use up the same > bandwidth. And the only good this does is to try and make the > connections throttle themselves when they notice that packets aren't > getting through. TCP does this, and a few application level UDP > protocols do this, but not much else. > > So, to your *goal* in a single sentence: > > Force TCP to send packets slower than your downlink speed. > > If you can manage this, then no packets are queued at your ISP and you > can prioritise traffic perfectly on your router. > > So, how does TCP work, then? > > On a connection, TCP has a window size in both directions, which is > the amount of new packets that can be transferred without getting an > acknowledgement for the packets already sent. Every packet sent is > put on a re-send queue, and removed from there when an > acknowledgement is received for that packet. If an acknowledgement > doesn't arrive for a while, the packet is re-sent. > > So what happens when a packet is dropped, is that the connection > stalls for a moment, because a packet is unacknowledged and send > window limits the amount of packets that can be in transit. TCP > stacks also throttle themselves when they notice that packets are > being dropped. > > Traditionally, the maximum window size was 64kb - that is, a maximum > of 64kbs of data can be unacknowledged on the link. Then the > internet became full of links which have a large bandwidth, but also > lots of latency. TCP window scaling was invented, and now window > sizes can be much larger than that. > > Also, traditionally TCP only acknowledged up to the last continguous > packet - that is, it wouldn't send acknowledgements for the packets > that arrived after the missing packet. A loss of a single packet > usually caused a short stall in the connection. This was augmented > by cool retransmission logic, which allowed TCP to recover from the > dropping of a single packet without a stall. And yet later selective > acknowledgements were invented, which allows TCP to tell the other > end exactly which packets it is missing, and now TCP survives quite > high packet loss reasonably well. > > So, what's the solution? How to make TCP throttle properly? > > The *real* solution would be to implement a packet mangler which > would mutilate outgoing TCP ACK packets such that it would only give > out transmission windows with the speed the link is configured > to. However, to my knowledge, no free software implements this. I > might work up a patch later, if I can come up with a good design. > > But, short of implementing the *real* solution, there are several > things you can do to improve the situation. But first, let's see what > is happening now. > > Right now, your scripts shove all incoming traffic to a HTB, inside > which the selection of packets happens through ESFQ. The HTB has to > be limited to a rate *smaller* than the actual downlink for it to > have any effect what so ever. And even so, what you do is that you > queue (eg. delay) packets (maximum of 128 packets as per ESFQ), and > then drop fairly traffic that comes faster. > > So what does TCP do about it? Latency is higher because of queueing > at your router, or queuing at the ISP, so the large window sizes > allow for a lot of packets to be in transit, waiting to be > transferred. A bunch of packets are dropped, so those are > retransmitted as soon as possible (at the arrival of the next > selective acknowledgement), again f
[LARTC] 95th percentile billing
I am just in the process of swapping ip transit supplier and my new supplier is providing an open 100Mb/s connection but billing me on the basis of using less than 1Mb/s for 95% of the time What would be the ideal for me would be setting up my box so that it always complied with this. i.e i want to limit my own connection speed to 1Mb/s but have a suitably large bit bucket so that i can burst higher for short periods The ideal would be a setup where the average speed cap worked out over serveral hours. If this were not possible even a few seconds of burst would help given that most of the files being downloaded from the webserver are only a few k Is something along these lines possible or have i miss understood the documentation -- Will Tatam Email / JID [EMAIL PROTECTED] Web www.netmindz.net PGP Key www.netmindz.net/will/will_tatam.asc Registered Linux user 294695 Linux Counter http://counter.li.org See http://www.jabber.org/ to find out more about the most advanced cross platform, open source enterprise messaging solution ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] packet discarding
Hi, I am stuggling in packets discarding whenever the packets are exceeding bandwidth. I like to delete/drop/discard the packet on source based whenever it exceeds the specified bandwidth. Pls. help me with sample coding/techniques. Regards, Kalaiselvan.
[LARTC] redhat 9 and htb
Hi everyone, I have RH9 2.4.20-28.0 with iproute-2.4.7-7.90.1 installed. But when I try tc qdisc add dev eth0 root handle 1:0 htb default 12 Unknown qdisc "htb", hence option "default" is unparsable. There are some others settings that must be done in kernel? I search the archive but I saw that some people with same versions of rh9 and iproute don't get this errors Thank you :) -- Razvan Stranschi [EMAIL PROTECTED] --- This e-mail was scanned for viruses by ARVO. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Latency low enough for gaming
Patrick Petersen wrote: Welcome to me, and my very first lartc post. As with most first timers, i made a mistake. Admin, disregard the earlier message, as i was still waiting for the subscription confirmation. Should it get through still, i apoligize. For the last few weeks i have been trying to make it so our 2048/512 adsl line can be used for gaming and for leeching at the same time. The current result is what can be found at http://www.schmakk.dk/~schmakk which is what is running at the NAT gateway. This has done a lot for the latency, but still there is huge problems with eg. massive http downloads (5+ threads makes ping go up to at least 200). I have learned a lot from the lartc list archive, but this specifik leaves me with no clue. I have been able to get real close to normal latency by capping incoming traffic at around 1200kbits, but its no fun throwing away almost half your bandwidth. Can i get any recommendations? Also, if you have the time, a look through my script is much appreciated. (Im concerned about the calculations for dividing the bandwidth, the general setup of everything and the ipp2p+connmark tagging.) I see you have a newer version now anyway, but I tried you script last night (not connmark/ipp2p as it clashed with connbytes). I have 256/512 so things in theory should be nicer for you. I am still testing myself, so can't post a solution but can make some observations - The delete rule for iptabled needs -D not -A. esfq won't work hashing src on egress if you are doing NAT see the KPTD on www.docum.org - egress qos comes after NAT. Ingress with dst should be ok if you are NATing as long as you used the IMQ NAT patch. The trouble with esfq hashing per user (unless you use limit) is that each user gets a 128 packet queue, which if they have many connections gets full and drops take a long time to be noticed. I have a modified esfq which overcomes this somewhat, but I also use classic hash and restrict the size of the queue. I can see why commercial bandwidth controllers use advertised window manipulation - often dropping is needed to get the sender to back off a bit and set its' congestion window, but if you queue this may result in a resync burst later. Being able to reduce adv window on dups/sacks and increase slowly/randomly would be handy. One thing that helps me is to give new bulk connections their own class with a short queue for the first 8 bytes using connbytes (netfilter extra patch). This is limited to rate downrate/5 ceil /3 and stops tcp slowstart from overshooting. I have also tried connbytes just to drop early packets, but with browsers making many simultaneous connections, the resyncs cause a latency burst. I see you are trying RED - in theory this should be nice, but remember the settings/docs you read about don't take into account that you are trying to shape behind a fifo (at ISP/teleco) that dequeues only 20% faster than what you are aiming for. I am not convinced that just dropping ingress is best - a short queue yes, then at least you don't ever drop game packets. If I had 2048 down I reckon I could keep down below 100 now - apart from the odd 1 sec blip. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] How does it look like when IMQ crashes?
Hi, when the IMQ-device crashes, how does it look like? Should there be an error message somewhere or is the network simply dead or does the machine get high load etc etc. or machine freeze? The context is that I've successfully used the IMQ-device for pure download shaping on an adsl line. now when I use exactly the same system with an ISDN-card instead of adsl, the system freezes from time to time. thx cb ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
