Don Cohen wrote: >Patrick McHardy writes: > > >We're adding an htb as the qdisc for a child class of htb ? Why? > > >Isn't that just wasting time? Can't all 10: stuff be done with 1: > > >instead? > > > > > The root qdisc is used for delay simulation, 10:0 is the "real" qdisc > > ( http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio ) > >So I was right, just to waste time. That was not part of the spec, as >I recall. So I suggest it be removed from the example. > I don't know if its really necessary, but as imq is a software device it probably is .. maybe devik can answer this ... > > > > If more than one imq device is used you specify the one which should get > > the packet with --todev argument to IMQ target. > >Be sure to put that in the doc. I didn't see it there. >I suppose the default is imq0 ? > yes .. > > > > skb->dev doesn't get changed if thats what you mean .. > >Ok, important to know that. I gather there is currently no way to >read the imq mark from netfilter. > currently not, but if you need something like this just change the mark match to match skb->imq_flags instead of skb->nfmark ... you should then look at include/linux/imq.h to see the meaning of the different bits. > > > > >When the packet is eventually dequeued (if not dropped) then it > > >goes where? I'm hoping it goes to the beginning of pre-routing > > >so we can apply conntrack/nat/mangle rules to it with -i imq0. > > > > > No it doesn't. I think it doesn't make any sense to use any kind of > > iptables rules on packets > > passing imq because all of them come from/go to real devices which you > > can use in your rules. > >But if you could read the imq mark then it would make a lot of sense. >These two things in combination would allow me to do what I want >without changing the code. As it is, it looks like I need a local >variant of IMQ that runs before conntrack. (On the other hand, this >is probably the more efficient solution anyhow.) > more efficient maybe, but you will loose the possibility to only donate bandwidth to established and assured connections by using the state match .. > > > > >I suspect this is not the case, since I see in the patch code > > > nf_reinject(skb, info, NF_ACCEPT) > > >I'm not even sure netfilter supports what I want. > > >I see in > > > http://netfilter.samba.org/documentation/HOWTO//netfilter-hacking-HOWTO-3.html > > > 5.NF_REPEAT: call this hook again. > > >but what's "this hook" ? Is it the imq hook or pre_routing ? > > > > > it's imq hook. from net/core/netfilter.c: > > nf_reinject(...) > >As I thought, there's no convenient way for you to do what I want. > > > you can easily change this order. i guess you already noticed if you > > looked at the imq source. > >Right. But this is not a change that everyone would want. > > > but are you sure this is necessary ? i guess your connection must be > > extremly fast if someone > > wants to dos you through a connection tracking table fillup attack ... > >My idea of extremely fast has changed recently. Maybe it's a bit >ahead of yours. First, I'm interested in protecting against attacks >from inside the firewall, and these are typically connected at >100Mbit. Is that fast enough? Next I've been playing with gigabit >cards. Finally I visited sprint a few weeks ago and they're not >interested in anything as slow as one gigabit. Although, for a >firewall, I admit that seems fast enough for the time being. > > > Changing skb->dev to imq0 would result in something like this: > > ... -> NF_HOOK(..) -> imq -> qdisc -> reinject -> continue NF_HOOK -> > > ... -> dev_queue_xmit -> qdisc -> imq -> reinject (CRASH!) > >If you mean it could result in infinite loops, yes, but this is not >the first invention of infinite loops. If your rules do the right >things then the loops can also be avoided. Besides, that requires >my other request, that the reinject go back to the beginning of the >prerouting hook. Without that it was completely plausible that the >skb dev could have been changed. But I'm not complaining. I just >wanted to know. > > > If you look at the imq source you find a imq_skb_destructor, i though > > about adding a comment that > > it's meant to save rusty's life. if skb's are freed inside qdiscs > > kfree_skb will call the destructor which > > will do necessary things to protect rusty :) >Ok, I wouldn't want to contribute to his early demise. This tends to >confirm my first guess, which was that the important thing here was to >free skbs when they are no longer in use. I guess user mode can't free >them, but perhaps the better solution would have been to free them >before a copy is sent to user space and then recreating them if the >copy ever came back. But I digress... > userspace ?? imq never sends anything to userspace, but if it really would then you're right, userspace can't free skbs. also the destructor doesn't free them but it releases references hold on the real devices which are taken before by netfilter so the real device doesn't vanish while the packet is out of netfilters control .. > > >Thanks for all the answers. > Your welcome, Patrick _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
