Hi! I''ve completed a pre-release of the new IMQ device. Changes include: - Multiple IMQ devices - Selection of what gets queued to which device is done using an iptables target, nothing gets queued be default - Ingress support (egress qdiscs can be used for ingress traffic control!) - Possible to build as a module Sources and somewhat confuse instructions can be found at http://luxik.cdi.cz/~patrick/imq . Bye, Patrick
good work ;) Please change Devara=>Devera .. I also changed original page http://luxik.cdi.cz/~devik/qos/imq.htm to mention your new one at beginning. Also why there are four imqs ? I can''t find way how to direct packet to partiticular one .... devik On Thu, 4 Apr 2002, Patrick McHardy wrote:> Hi! > > I''ve completed a pre-release of the new IMQ device. > Changes include: > - Multiple IMQ devices > - Selection of what gets queued to which device is done using an iptables > target, nothing gets queued be default > - Ingress support (egress qdiscs can be used for ingress traffic control!) > - Possible to build as a module > > Sources and somewhat confuse instructions can be found at http://luxik.cdi.cz/~patrick/imq . > > Bye, > Patrick > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
Oops, forgot to reply to the list. On Thu, 4 Apr 2002, Martin Devera wrote:> Also why there are four imqs ? I can''t find way how to > direct packet to partiticular one ....The IMQ iptables target has an option --todev to specify to which imq device a packet should go. if it''s not specified it defaults to 0. Bye Patrick
> - Ingress support (egress qdiscs can be used for ingress traffic control!)Ehhhhhh, I can''t believe it !! Yahgooooooooo
Hello to list and Patrick !
scuse me first for my bad english:)
I''m using the new IMQ code since 2 days, and it''s very
efficient!
but i''ve experimented a bad problem, that i doesn''t manage to
resolve.
for example I load these simple rules:
tc qdisc add dev imq0 handle 1: root htb default 1
tc class add dev imq0 parent 1: classid 1:1 htb rate 500kbit burst 30k
tc qdisc add dev imq0 parent 1:1 handle 21:0 sfq
tc filter add dev imq0 protocol ip parent 1: handle 10 fw classid 1:1
iptables -t mangle -A PREROUTING -i ppp0 -j IMQ
iptables -t mangle -A PREROUTING -i ppp0 -j MARK --set-mark 10
ip link set imq0 up
the result in the syslog is (at the first network activity)
"kernel: nf_hook: Verdict = QUEUE."
and quickly become:
"kernel: last message repeated 6 times"
the real problem is that I''ve experimented a silent Crash this morning
but before using IMQ this machine was rock stable (months without crash)
the only usable log of it is:
Apr 8 10:03:55 way kernel: nf_hook: Verdict = QUEUE.
Apr 8 10:04:26 way last message repeated 1533 times
Apr 8 10:05:27 way last message repeated 2982 times
Apr 8 10:06:28 way last message repeated 2808 times
Apr 8 10:07:29 way last message repeated 2837 times
Apr 8 10:08:30 way last message repeated 2841 times
Apr 8 10:09:31 way last message repeated 3008 times
>> crash here, pc completely freezed <<
Apr 8 10:21:08 way syslogd 1.4.1: restart.
Configuration:
o kernel 2.4.18 with HTB patch,
o netfilter/iptables v1.2.6a from CVS, ppp0 is kernel mode pppoe,
o iproute2-ss020116 compiled with HTB patch
So, is it a bug, or a misconfiguration ?
tanks a lot!:)
curio / a QoS addicted french guy :)
Hi Simond. "SIMOND François" schrieb:> > Hello to list and Patrick ! > scuse me first for my bad english:) > > I''m using the new IMQ code since 2 days, and it''s very efficient! > but i''ve experimented a bad problem, that i doesn''t manage to resolve. > > for example I load these simple rules:...> the result in the syslog is (at the first network activity) > "kernel: nf_hook: Verdict = QUEUE." > and quickly become: > "kernel: last message repeated 6 times"This means you have compiled your kernel with netfilter debugging turned on. Turn it off and the message will disappear.> the real problem is that I''ve experimented a silent Crash this morning > but before using IMQ this machine was rock stable (months without crash) > the only usable log of it is: >Sorry about that :) It IS a bug and it has been fixed, i will put out a new version tonight. The problem was that packets returned later from non-work-conserving qdiscs were passed on to registered network interface taps twice and somewhere there a null pointer reference occured. PS: Please write bugreports directly to me
Hi Simond. "SIMOND François" schrieb:> > Hello to list and Patrick ! > scuse me first for my bad english:) > > I''m using the new IMQ code since 2 days, and it''s very efficient! > but i''ve experimented a bad problem, that i doesn''t manage to resolve. > > for example I load these simple rules:...> the result in the syslog is (at the first network activity) > "kernel: nf_hook: Verdict = QUEUE." > and quickly become: > "kernel: last message repeated 6 times"You have compiled your kernel with NETFILTER DEBUGGING, turn it off and it will disappear.> the real problem is that I''ve experimented a silent Crash this morning > but before using IMQ this machine was rock stable (months without crash) > the only usable log of it is:> So, is it a bug, or a misconfiguration ?Sorry about that, it IS a bug :( It has been fixed and i will put out a new version tonight. The problem was that packets passed through non-work-conserving qdiscs were delivered to dev_queue_xmit_nit twice and somewhere there a NULL pointer reference occured. PS: In the future please send bugreports directly to me or at least CC Bye, Patrick
> > So, is it a bug, or a misconfiguration ? > > Sorry about that, it IS a bug :( > It has been fixed and i will put out a new version tonight. > The problem was that packets passed through non-work-conserving qdiscs > were delivered to dev_queue_xmit_nit twice and somewhere there a NULL > pointer reference occured. > > PS: In the future please send bugreports directly to me or at least CChappy hacking patrick ;) When I have written HTB I suspect that all will go well. A week later I spend whole days catching bugs people reported. Sometimes very tricky ones .... nice to see another active developer in field ! Let Power be with you Patrick ;) devik
Martin Devera schrieb:> happy hacking patrick ;) When I have written HTB I suspect > that all will go well. A week later I spend whole days catching > bugs people reported. > Sometimes very tricky ones ....Yeah the problem was i wrote the new imq during easter holidays while i was staying at my parents on my laptop so i hadn''t got a chance to extensively test it .. As soon as i tried it on my router it also crashed :) The new version i promised for yesterday is not out yet, i will probably put it out tonight after some more testing ..> nice to see another active developer in field ! > Let Power be with you Patrick ;):) I thought about changing qos subsystem to support real ingress queueing without imq or something. Kind of two root qdiscs per device. What do you (and others) think about this ? Bye, Patrick
> > nice to see another active developer in field ! > > Let Power be with you Patrick ;) > :) > > I thought about changing qos subsystem to support real ingress queueing > without imq or something. Kind of two root qdiscs per device. What do > you > (and others) think about this ?There already is somethink like it (ingres) only it doesn''t queue .. IMO the main problem will be to understand whole machinery in sch_generic.c and likes. Also Jamal and Alexey are against this ... But I think it is worth of doing it. Especially in 2.4 where we have both rx and tx softirqs it should not be so comlicated to do it. devik
Martin Devera schrieb:> > I thought about changing qos subsystem to support real ingress queueing > > without imq or something. Kind of two root qdiscs per device. What do > > you > > (and others) think about this ? > > There already is somethink like it (ingres) only it doesn''t queue ..:) In my eyes current ingres is just a hack.> IMO the main problem will be to understand whole machinery in > sch_generic.c and likes. > Also Jamal and Alexey are against this ... But I think it is worthWhy ? I guess IMQ prooves ingress shaping DOES work so i can''t see any good reason ..> of doing it. Especially in 2.4 where we have both rx and tx softirqs > it should not be so comlicated to do it.One problem i see is that unlike imq it would probably be placed in net_rx_action so you can''t use netfilter marks for filters which i guess is really bad for ingress because without iptables you cannot use any kind of connection state etc. information for filters so preventing DOS will be much harder, but that will probably remain unsolvable .. Patrick