IMQ bug: kernel reboot immediately

IMQ bug: kernel reboot immediately

[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?

Thanks,
Shawn
 				
--------------
Y. D.
2009-04-22

Re: IMQ bug: kernel reboot immediately

[Jarek Poplawski]

On 22-04-2009 17:27, Y. D. wrote:
> 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.

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Jarek Poplawski wrote:
> On 22-04-2009 17:27, Y. D. wrote:
>> 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.

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.

Re: IMQ bug: kernel reboot immediately

[Jan Engelhardt]

On Thursday 2009-04-23 12:20, Patrick McHardy wrote:

>>> 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.

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.

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-04-23 12:20, Patrick McHardy wrote:
> 
>>>> 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.
> 
> 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.

Re: IMQ bug: kernel reboot immediately

[Salatiel Filho]

On Thu, Apr 23, 2009 at 07:28, Patrick McHardy <kaber@trash.net> wrote:
> Jan Engelhardt wrote:
>>
>> On Thursday 2009-04-23 12:20, Patrick McHardy wrote:
>>
>>>>> 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.
>>
>> 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 ... :)




> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
[]'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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Salatiel Filho wrote:
> On Thu, Apr 23, 2009 at 07:28, Patrick McHardy <kaber@trash.net> wrote:
>> 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 ... :)

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.

Re: IMQ bug: kernel reboot immediately

[Jarek Poplawski]

On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
...
> 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.

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Jarek Poplawski wrote:
> On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
> ...
>> 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?

Re: IMQ bug: kernel reboot immediately

[Jarek Poplawski]

On Thu, Apr 23, 2009 at 01:46:10PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
>> ...
>>> 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?

There is nothing specific yet. I hope these other classifiers and
actions aren't mislead too much to go astray.

Jarek P.

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Jarek Poplawski wrote:
> On Thu, Apr 23, 2009 at 01:46:10PM +0200, Patrick McHardy wrote:
>> Jarek Poplawski wrote:
>>> On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:
>>> ...
>>>> 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?
> 
> 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.

Re: IMQ bug: kernel reboot immediately

[Salatiel Filho]

On Thu, Apr 23, 2009 at 08:22, Patrick McHardy <kaber@trash.net> wrote:
> Salatiel Filho wrote:
>>
>> On Thu, Apr 23, 2009 at 07:28, Patrick McHardy <kaber@trash.net> wrote:
>>>
>>> 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 ... :)
>
> 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 ?


-- 
[]'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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Salatiel Filho wrote:
> On Thu, Apr 23, 2009 at 08:22, Patrick McHardy <kaber@trash.net> wrote:
>> Salatiel Filho wrote:
>>> 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.
>>
>>
> 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.

Re: IMQ bug: kernel reboot immediately

[Salatiel Filho]

On Thu, Apr 23, 2009 at 09:41, Patrick McHardy <kaber@trash.net> wrote:
> Salatiel Filho wrote:
>>
>> On Thu, Apr 23, 2009 at 08:22, Patrick McHardy <kaber@trash.net> wrote:
>>>
>>> Salatiel Filho wrote:
>>>>
>>>> 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.
>>>
>>>
>> 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.


>
>



-- 
[]'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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Salatiel Filho wrote:
> On Thu, Apr 23, 2009 at 09:41, Patrick McHardy <kaber@trash.net> wrote:
>> Salatiel Filho wrote:
>>> 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.

> 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.

Re: IMQ bug: kernel reboot immediately

[Denys Fedoryschenko]

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.

Re: IMQ bug: kernel reboot immediately

[Salatiel Filho]

On Fri, Apr 24, 2009 at 11:55, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> 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


-- 
[]'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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Salatiel Filho wrote:
> On Fri, Apr 24, 2009 at 11:55, Denys Fedoryschenko <denys@visp.net.lb> wrote:
>> 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

DRR. But it can't do those strange load-balancing hacks.

Re: IMQ bug: kernel reboot immediately

[Salatiel Filho]

On Fri, Apr 24, 2009 at 12:19, Patrick McHardy <kaber@trash.net> wrote:
> Salatiel Filho wrote:
>>
>> On Fri, Apr 24, 2009 at 11:55, Denys Fedoryschenko <denys@visp.net.lb>
>> wrote:
>>>
>>> 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
>
> DRR. 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 ?

-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: IMQ bug: kernel reboot immediately

[Patrick McHardy]

Salatiel Filho wrote:
> On Fri, Apr 24, 2009 at 12:19, Patrick McHardy <kaber@trash.net> wrote:
>> Salatiel Filho wrote:
>>> 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.
>>
> 
> what would it be those strange ugly hacks ? :)

Look at the code. At least they were there last time I had a look.

> 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.

Re: Re: IMQ bug: kernel reboot immediately

[Y. D.]

>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

Re: Re: IMQ bug: kernel reboot immediately

[Jarek Poplawski]

On Thu, Apr 23, 2009 at 08:29:06PM +0800, Y. D. wrote:
> 
> >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.

Re: IMQ bug: kernel reboot immediately

[pud]

On Wed, 22 Apr 2009, Y. D. wrote:

> 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

-- 
gpg-key #C3B04767