From: Justin Schoeman <justin@expertron.co.za>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Traffic control and logging?
Date: Thu, 04 Nov 2004 12:00:38 +0000 [thread overview]
Message-ID: <418A19E6.4040306@expertron.co.za> (raw)
In-Reply-To: <4187AC55.2040705@expertron.co.za>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
OK - judging by the lack of response, I am assuming this is not possible?
I have started hacking on a simple patch to add support to qdiscs to dup
their traffic to a dummy interface.
Simple test code for the prio qdisc, hardcoded for device id 5 as the
dummy qdisc is attached.
The eventual idea is to add an optional argument 'dupdev' to all qdiscs.
If the qdisc has this argument set, then the packet is duplicated to
that device, if not, nothing is altered.
The only real overhead is one NULL check in each enqueue function, so
this should not really affect performance.
Is it worth while doing up this solution as a proper kernel patch (does
it have any chance of being accepted, or should I just do it
'quick-and-dirty' for my personal use?
Thanks,
Justin
Justin Schoeman wrote:
> Hi all, I am new to tc on Linux, and am having some problems. The basic
> set-up and use works wonderfully, but now I have run into a slight
> problem...
>
> I am using tc qdiscs and filters to do my traffic shaping. Now, I have
> a whole bunch of filters to classify the data, and they work well,
> however, after all my classifications are done, I still have data
> reaching the default flow. ALL of the data should have been classified -
> so I would really like to look at the data that is still not classified.
> Is there any way to log these packets? Can any of the qdiscs log queued
> traffic in a sane way? Can I forward the traffic back to iptables in
> some way?
>
> Any help would be greatly appreciated.
>
> Thanks,
> Justin
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[-- Attachment #2: dup.patch --]
[-- Type: text/plain, Size: 1463 bytes --]
--- sch_prio.c.old 2004-11-04 04:21:46.000000000 +0200
+++ sch_prio.c 2004-11-04 03:36:07.000000000 +0200
@@ -44,6 +44,7 @@
struct tcf_proto *filter_list;
u8 prio2band[TC_PRIO_MAX+1];
struct Qdisc *queues[TCQ_PRIO_BANDS];
+ struct net_device * dup_dev;
};
@@ -99,7 +100,21 @@
prio_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
struct Qdisc *qdisc;
+ struct prio_sched_data *q = qdisc_priv(sch);
int ret = NET_XMIT_SUCCESS;
+
+ if(q->dup_dev) {
+ struct sk_buff * dup_skb = skb_copy(skb, GFP_ATOMIC);
+ if(!dup_skb) {
+ printk(KERN_ERR "Error copying packet.\n");
+ } else {
+ dup_skb->dev = q->dup_dev;
+ if(dev_queue_xmit(dup_skb) < 0) {
+ printk(KERN_ERR "Error queueing duplicate packet on '%s'.\n", q->dup_dev->name);
+ kfree_skb(dup_skb);
+ }
+ }
+ }
qdisc = prio_classify(skb, sch, &ret);
@@ -210,6 +225,11 @@
for (prio=0; prio<q->bands; prio++)
qdisc_destroy(q->queues[prio]);
+
+ if(q->dup_dev) {
+ dev_put(q->dup_dev);
+ q->dup_dev = NULL;
+ }
}
static int prio_tune(struct Qdisc *sch, struct rtattr *opt)
@@ -237,6 +257,13 @@
if (child != &noop_qdisc)
qdisc_destroy(child);
}
+
+ q->dup_dev = dev_get_by_index(5);
+ if(!q->dup_dev) {
+ printk(KERN_WARNING "PRIO: Network device 5 does not seem to exist?\n");
+ return -EINVAL;
+ }
+ printk(KERN_DEBUG "PRIO: Using device '%s' for dup'ing packets.\n", q->dup_dev->name);
sch_tree_unlock(sch);
for (i=0; i<=TC_PRIO_MAX; i++) {
next prev parent reply other threads:[~2004-11-04 12:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-02 15:48 [LARTC] Traffic control and logging? Justin Schoeman
2004-11-04 12:00 ` Justin Schoeman [this message]
2004-11-04 12:46 ` Thomas Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=418A19E6.4040306@expertron.co.za \
--to=justin@expertron.co.za \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.