IMQ bug: kernel reboot immediately
Subsystems (3)
Hi,
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
Any help with this kinda problem?
Thanks,
Shawn
--------------
Y. D.
2009-04-22
Quoted 8 lines · Y. D.
Hi,
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
Any help with this kinda problem?
IMQ isn't a part of kernel/netfilter, so you should try at its own site/mailing list.
Jarek P.
Quoted 8 lines · Jarek Poplawski
Quoted 7 lines · Y. D.
Hi,
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
Quoted 4 lines
Quoted 1 line
Any help with this kinda problem?
IMQ isn't a part of kernel/netfilter, so you should try at its own site/mailing list.
I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't been a single version in all those years that didn't cause this kind of problems.
Quoted 5 lines · Patrick McHardy
Quoted 5 lines
Quoted 5 lines
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Any help with this kinda problem?
IMQ isn't a part of kernel/netfilter, so you should try at its own site/mailing list.
I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't been a single version in all those years that didn't cause this kind of problems.
I'd rather point out that ifb does not seem to be able to do all of what IMQ can, up to the point where it is believed in the public that ifb is practically useless.
Quoted 7 lines · Jan Engelhardt
Quoted 5 lines · Patrick McHardy
Quoted 5 lines
Quoted 5 lines
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Any help with this kinda problem?
IMQ isn't a part of kernel/netfilter, so you should try at its own site/mailing list.
I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't been a single version in all those years that didn't cause this kind of problems.
I'd rather point out that ifb does not seem to be able to do all of what IMQ can, up to the point where it is believed in the public that ifb is practically useless.
I'm aware of those claims, but not of the details. If this is true, people should raise those issues and help resolve them. I wouldn't hold my breath waiting for IMQ to get fixed.
Quoted 18 lines · Patrick McHardy
Quoted 17 lines · Jan Engelhardt
Quoted 13 lines · Patrick McHardy
Quoted 9 lines
Quoted 6 lines
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
Any help with this kinda problem?
IMQ isn't a part of kernel/netfilter, so you should try at its own site/mailing list.
I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't been a single version in all those years that didn't cause this kind of problems.
Quoted 8 lines
Quoted 3 lines
I'd rather point out that ifb does not seem to be able to do all of what IMQ can, up to the point where it is believed in the public that ifb is practically useless.
I'm aware of those claims, but not of the details. If this is true, people should raise those issues and help resolve them. I wouldn't hold my breath waiting for IMQ to get fixed.
I would love to see a way to change where IFB hooks [if "hook" is the right term ], till now i dont think i am able to hook it after nat in prerouting and before nat in postrouting. Is there a way to do this ? What i basically do with IMQ is:
eth0 [192.168.0.0/24]
ppp0 <----> eth1 [192.168.1.0/24]
eth2 [192.168.2.0/24]Using imq i can shape upload on ppp0 [postrouting] while still having the internal private ips from the hosts, and i can shape download in ppp0 [prerouting] after get the correct nat'ed addresses.
Is there a way to achieve this in IFB ? in a simple way ... :)
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 9 lines
[]'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Salatiel Filho
Quoted 4 lines · Patrick McHardy
I'm aware of those claims, but not of the details. If this is true, people should raise those issues and help resolve them. I wouldn't hold my breath waiting for IMQ to get fixed.
I would love to see a way to change where IFB hooks [if "hook" is the right term ], till now i dont think i am able to hook it after nat in prerouting and before nat in postrouting. Is there a way to do this ? What i basically do with IMQ is:
eth0 [192.168.0.0/24] ppp0 <----> eth1 [192.168.1.0/24] eth2 [192.168.2.0/24]
Quoted 5 lines
Using imq i can shape upload on ppp0 [postrouting] while still having the internal private ips from the hosts, and i can shape download in ppp0 [prerouting] after get the correct nat'ed addresses.
Is there a way to achieve this in IFB ? in a simple way ... :)
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
Alternatively classifiers using conntrack information (like cls_flow) could perform the lookup directly, but that would probably get a bit ugly since some validation needs to be performed previously and it would add a module dependency on conntrack.
On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
...
Quoted 3 lines
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
BTW, some time ago I started to wonder how safe are those various ingress activities wrt. invalid packets, dropped later in ip_rcv().
Jarek P.
Quoted 8 lines · Jarek Poplawski
On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
...Quoted 3 lines
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
BTW, some time ago I started to wonder how safe are those various ingress activities wrt. invalid packets, dropped later in
ip_rcv().
Leaving aside the ipt action, I'm not aware of any problems caused by ingress classification. Could you be more specific?
Quoted 7 lines · Patrick McHardy
Quoted 6 lines · Jarek Poplawski
On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
...Quoted 3 lines
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
Quoted 5 lines
Quoted 2 lines
BTW, some time ago I started to wonder how safe are those various ingress activities wrt. invalid packets, dropped later in
ip_rcv().Leaving aside the ipt action, I'm not aware of any problems caused by ingress classification. Could you be more specific?
There is nothing specific yet. I hope these other classifiers and actions aren't mislead too much to go astray.
Jarek P.
Quoted 7 lines · Jarek Poplawski
Quoted 6 lines · Patrick McHardy
Quoted 5 lines · Jarek Poplawski
On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
...Quoted 3 lines
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
BTW, some time ago I started to wonder how safe are those various ingress activities wrt. invalid packets, dropped later in
ip_rcv().Leaving aside the ipt action, I'm not aware of any problems caused by ingress classification. Could you be more specific?
There is nothing specific yet. I hope these other classifiers and actions aren't mislead too much to go astray.
Generally, there shouldn't be any problems specific to ingress since the classifiers have to expect all kinds of invalid packets on egress as well.
Quoted 25 lines · Patrick McHardy
Quoted 18 lines · Salatiel Filho
Quoted 5 lines · Patrick McHardy
I'm aware of those claims, but not of the details. If this is true, people should raise those issues and help resolve them. I wouldn't hold my breath waiting for IMQ to get fixed.
I would love to see a way to change where IFB hooks [if "hook" is the right term ], till now i dont think i am able to hook it after nat in prerouting and before nat in postrouting. Is there a way to do this ? What i basically do with IMQ is:
eth0 [192.168.0.0/24]
ppp0 <----> eth1 [192.168.1.0/24]
eth2 [192.168.2.0/24]Quoted 5 lines
Using imq i can shape upload on ppp0 [postrouting] while still having the internal private ips from the hosts, and i can shape download in ppp0 [prerouting] after get the correct nat'ed addresses.
Is there a way to achieve this in IFB ? in a simple way ... :)
Quoted 10 lines
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
Alternatively classifiers using conntrack information (like
cls_flow) could perform the lookup directly, but that would probably get a bit ugly since some validation needs to be performed previously and it would add a module dependency on conntrack.
Using this actions would make sfq hashing by dest ip or source ip work just like it works in imq ?
Signature · 9 lines
[]'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Salatiel Filho
Quoted 10 lines · Patrick McHardy
Quoted 5 lines · Salatiel Filho
Using imq i can shape upload on ppp0 [postrouting] while still having the internal private ips from the hosts, and i can shape download in ppp0 [prerouting] after get the correct nat'ed addresses.
Is there a way to achieve this in IFB ? in a simple way ... :)
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
Quoted 8 lines
Quoted 6 lines
Alternatively classifiers using conntrack information (like
cls_flow) could perform the lookup directly, but that would probably get a bit ugly since some validation needs to be performed previously and it would add a module dependency on conntrack.Using this actions would make sfq hashing by dest ip or source ip work just like it works in imq ?
Not with the SFQ default hash since it classifies based on the addresses in the IP header. But you could use the flow classifier, which can use the addresses from the conntrack entry. This would behave similar to IMQ+SFQ.
Quoted 22 lines · Patrick McHardy
Quoted 21 lines · Salatiel Filho
Quoted 19 lines · Patrick McHardy
Quoted 6 lines · Salatiel Filho
Using imq i can shape upload on ppp0 [postrouting] while still having the internal private ips from the hosts, and i can shape download in ppp0 [prerouting] after get the correct nat'ed addresses.
Is there a way to achieve this in IFB ? in a simple way ... :)
Currently not, the conntrack association is done at a later point. We could add a classifier or TC action that performs the lookup during ingress classification.
Alternatively classifiers using conntrack information (like
cls_flow) could perform the lookup directly, but that would probably get a bit ugly since some validation needs to be performed previously and it would add a module dependency on conntrack.
Quoted 7 lines
Quoted 2 lines
Using this actions would make sfq hashing by dest ip or source ip work just like it works in imq ?
Not with the SFQ default hash since it classifies based on the addresses in the IP header. But you could use the flow classifier, which can use the addresses from the conntrack entry. This would behave similar to IMQ+SFQ.
Ok , i was tying to keepthe discussion to the mainline kernel :) By sfq i mean esfq [though i read somewhere sfq will implement a way to hash by src / dest ip] , or wrr :)
Actually i was never able to find out why wrr is not in mainline kernel. In my opinion it is the best round robin qdisc i have ever used.
Quoted 2 lines
Signature · 9 lines
[]'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Salatiel Filho
Quoted 9 lines · Patrick McHardy
Quoted 3 lines · Salatiel Filho
Using this actions would make sfq hashing by dest ip or source ip work just like it works in imq ?
Not with the SFQ default hash since it classifies based on the addresses in the IP header. But you could use the flow classifier, which can use the addresses from the conntrack entry. This would behave similar to IMQ+SFQ.
Ok , i was tying to keepthe discussion to the mainline kernel :)
The flow classifier is in the mainline kernel.
Quoted 5 lines
By sfq i mean esfq [though i read somewhere sfq will implement a way to hash by src / dest ip] , or wrr :)
Actually i was never able to find out why wrr is not in mainline kernel. In my opinion it is the best round robin qdisc i have ever used.
There is DRR since a couple of versions. Combined with the flow classifier, it should provide the same functionality as ESFQ.
Quoted 4 lines · On Friday 24 April 2009 17:49:14 Patrick McHardy wrote:
There is DRR since a couple of versions. Combined with the flow classifier, it should provide the same functionality as ESFQ.
I think it is even better, as soon as you understand it, it is very intuitive to understand and transparent, how it works.
Quoted 8 lines · Denys Fedoryschenko
Quoted 4 lines · On Friday 24 April 2009 17:49:14 Patrick McHardy wrote:
There is DRR since a couple of versions. Combined with the flow classifier, it should provide the same functionality as ESFQ.
I think it is even better, as soon as you understand it, it is very intuitive to understand and transparent, how it works.
I am just curious , is there a qdisc in mainline that behaves similar to wrr [weight round robin] ?
http://www.zz9.dk/wrr
Signature · 9 lines
[]'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente". -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Salatiel Filho
Quoted 4 lines · Denys Fedoryschenko
Quoted 3 lines · On Friday 24 April 2009 17:49:14 Patrick McHardy wrote:
There is DRR since a couple of versions. Combined with the flow classifier, it should provide the same functionality as ESFQ.
Quoted 7 lines
Quoted 3 lines
I think it is even better, as soon as you understand it, it is very intuitive to understand and transparent, how it works.
I am just curious , is there a qdisc in mainline that behaves similar to wrr [weight round robin] ?
http://www.zz9.dk/wrr
DRR. But it can't do those strange load-balancing hacks.
Quoted 16 lines · Patrick McHardy
Quoted 15 lines · Salatiel Filho
Quoted 11 lines · Denys Fedoryschenko
Quoted 4 lines · On Friday 24 April 2009 17:49:14 Patrick McHardy wrote:
There is DRR since a couple of versions. Combined with the flow classifier, it should provide the same functionality as ESFQ.
I think it is even better, as soon as you understand it, it is very intuitive
to understand and transparent, how it works.
Quoted 6 lines
Quoted 3 lines
I am just curious , is there a qdisc in mainline that behaves similar to wrr [weight round robin] ?
http://www.zz9.dk/wrrDRR. But it can't do those strange load-balancing hacks.
what would it be those strange ugly hacks ? :)
Any good place where i can find DRR documentation/examples ?
Signature · 5 lines
[]'s Salatiel "O maior prazer do inteligente é bancar o idiota diante de um idiota que banca o inteligente".
Quoted 9 lines · Salatiel Filho
Quoted 6 lines · Patrick McHardy
Quoted 3 lines · Salatiel Filho
I am just curious , is there a qdisc in mainline that behaves similar to wrr [weight round robin] ?
http://www.zz9.dk/wrrDRR. But it can't do those strange load-balancing hacks.
what would it be those strange ugly hacks ? :)
Look at the code. At least they were there last time I had a look.
Quoted 1 line
Any good place where i can find DRR documentation/examples ?
No, but I can give you an example:
tc qdisc add dev <dev> parent <parent> handle <handle> drr
tc class add dev <dev> parent <handle> classid <classid> drr
repeat class add as often as you need. The default quantum per class is the MTU, including link layer headers. You can manually change that by specifying the "quantum" parameter for classes.
As for the flow classifier:
tc filter add dev <dev> protocol all pref 1 parent <handle> \
flow hash keys key1,key2,... divisor <number of classes>
The DRR classids need to be consequitive for this to work.
Quoted 4 lines
I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't been a single version in all those years that didn't cause this kind of problems.
Thanks for your information.
I just want to shape ingress traffic with my own qdisc, shoule it be IMQ or IFB. I am wondering where I can get a little detailed usage guide about IFB. ANY clue?
Thank you,
Shawn
Quoted 9 lines · Y. D.
Quoted 4 lines
I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't been a single version in all those years that didn't cause this kind of problems.
Thanks for your information.
I just want to shape ingress traffic with my own qdisc, shoule it be IMQ or IFB. I am wondering where I can get a little detailed usage guide about IFB. ANY clue?
There is doc/actions/ifb-README in iproute2 sources. And google as usual...
Jarek P.
Quoted 4 lines · Y. D.
Is IMQ still maintained? I am using IMQ to shape ingress traffic. But the application is a streaming server (VLC). However, the kernel reboots immediately as quick as can hardly been seen what is wrong with it.
wrong list i guess :)
latest working patches that were posted on imq-list are available here:
http://www.student.oulu.fi/~jukivili/imq/
i know that esp. netdev (sorry, i'm not subscribed there) folks don't like imq so much,
but because documentation for ifb and related stuff really sucks (for users) a lot of people stick to imq, even if ifb might be a better solution, technically
[really, for all (a)dsl users it's no alternative, yet]
but... if anyone wants to have a look at that patches, give some (constructive) feedback, you're welcome
i'll forward them to imq list, if you like
=;p/ud aka nerdpunk
Signature · 1 line
gpg-key #C3B04767