I setup the "Ultimate Traffic Conditioner" script on one of my 56k
modem
lines, and every time it effectively kills the link. The specific problem
is the ingress filter/rate limiter lines (which was what I really wanted)
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
After quite a bit of searching, I finally found another person posted this
exact problem to the list a few months ago, but the answer they got was to
try another approach. Before I spend time trying to figure out how to
use that approach, I thought I would check if anything more has been
discovered about this. Like the person who originally reported this, I am
also running a 2.4.18 kernel, and as soon as I activate the filter
(regardless of settings), the link is effectively dead until I remove the
filter, presumably all incoming packets are being blocked. I have tried
many variations, including setting the rate much higher than the link can
provide (so presumably the limit will never be reached), and even
switching from "drop" to "continue" or "pass", and
even in these cases,
all the data gets blocked. Unless I am misunderstanding something here,
there would appear to be a serious bug somewhere in the kernel or tc
command. Anyone know anything more about this? Has anyone gotten this to
work with a 2.4.18 kernel? If not, what is the most recent kernel and tc
command combination that does work?
Thanks for any enlightenment you can provide.
Shannon C. Dealy | DeaTech Research Inc.
dealy@deatech.com | - Custom Software Development -
| Embedded Systems, Real-time, Device Drivers
Phone: (800) 467-5820 | Networking, Scientific & Engineering Applications
or: (541) 451-5177 | www.deatech.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/