Nils Lichtenfeld schrieb:
> Hello Patrick!
Hi Nils,
> From: "Patrick McHardy" <kaber@trash.net>
> > > this is only internal mark to know whether the skb was
> > > already in IMQ. You could use it but you would have to
> > > add new user parameter to the interface structure.
> > > I didn't want to do it as I want the pach to be as simple
> > > as possible.
> > > devik
>
> > The same problem was bugging me a couple of days ago so i wrote an
> > iptables target which
> > allows you to exclude packets from beeing enqueued to the imq device.
> > The patch is tested with iptables-1.2.6a but should work with almost any
> > recent version.
> > After applying it you have to execute a "chmod +x
> > extensions/.IMQX-test", then
> > make patch-o-matic as usual.
>
> This sounds great and might be usefull in the future. We are still using 2.2.19
> here so no iptables atm.
I think you can easily write an ipchains modul which accomplishes the
same,
all you have to do is to set 'from_imq" to 1 in the skb.
A good start might be the MARK target, modifying (the iptables one) for
imq
took only a couple of minutes.
> By the way: Imagine the IMQ-device is allready up and a new ISDN-device is
> comming up, will the packages of the new ISDN-device automatically be send to
> IMQ or do I have to take the IMQ-device down and up again?
>From net/core/core.c:
int dev_queue_xmit(struct sk_buff *skb)
...
#ifdef CONFIG_IMQ
/* special intermediate queue up ? */
if (imq_dev.flags&IFF_UP && !skb->from_imq) {
spin_lock_bh(&imq_dev.queue_lock);
q = imq_dev.qdisc;
if (q->enqueue) {
int ret = q->enqueue(skb, q);
qdisc_run(&imq_dev);
spin_unlock_bh(&imq_dev.queue_lock);
return ret == NET_XMIT_BYPASS ? NET_XMIT_SUCCESS : ret;
}
spin_unlock_bh(&imq_dev.queue_lock);
}
#endif
...
So i would say everything will be going to the IMQ device automatically.
Bye,
Patrick
