From andrew.ruthven at catalyst.net.nz Mon Dec 3 19:20:09 2007 From: andrew.ruthven at catalyst.net.nz (Andrew Ruthven) Date: Tue, 04 Dec 2007 08:20:09 +1300 Subject: [dsc] IPv6 on some graphs have issues Message-ID: <1196709609.2927.3.camel@dirk.catalyst.net.nz> Hi, Is it possible to make the labels on the y axis longer for some of the graph types? IPv6 addresses can be somewhat ... unreadable. Have a look at the attached graph. Cheers! -- Andrew Ruthven, Wellington, New Zealand At work: andrew.ruthven at catalyst.net.nz At home: andrew at etc.gen.nz GPG fpr: 34CA 12A3 C6F8 B156 72C2 D0D7 D286 CE0C 0C62 B791 -------------- next part -------------- A non-text attachment was scrubbed... Name: ipv6-client-subnets.png Type: image/png Size: 7663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wessels at measurement-factory.com Tue Dec 4 21:25:45 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Tue, 4 Dec 2007 14:25:45 -0700 (MST) Subject: [dsc] IPv6 on some graphs have issues In-Reply-To: <1196709609.2927.3.camel@dirk.catalyst.net.nz> References: <1196709609.2927.3.camel@dirk.catalyst.net.nz> Message-ID: <20071204142455.H16210@measurement-factory.com> On Tue, 4 Dec 2007, Andrew Ruthven wrote: > Hi, > > Is it possible to make the labels on the y axis longer for some of the > graph types? IPv6 addresses can be somewhat ... unreadable. Have a > look at the attached graph. Heh, thanks for that. Also kind of silly to have them all show up as 'Unknown' too. I'll see what I can do to fix it. Duane W. From wessels at measurement-factory.com Wed Dec 5 00:42:26 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Tue, 4 Dec 2007 17:42:26 -0700 (MST) Subject: [dsc] IPv6 on some graphs have issues In-Reply-To: <1196709609.2927.3.camel@dirk.catalyst.net.nz> References: <1196709609.2927.3.camel@dirk.catalyst.net.nz> Message-ID: <20071204174156.F16210@measurement-factory.com> On Tue, 4 Dec 2007, Andrew Ruthven wrote: > Hi, > > Is it possible to make the labels on the y axis longer for some of the > graph types? IPv6 addresses can be somewhat ... unreadable. Have a > look at the attached graph. Let me know if this change gives enough room for all those v6 addrs: Index: presenter/perllib/DSC/grapher.pm =================================================================== --- presenter/perllib/DSC/grapher.pm (revision 9550) +++ presenter/perllib/DSC/grapher.pm (revision 9551) @@ -570,7 +570,7 @@ Ploticus_categories(1); my $areadef_opts = { -title => $PLOT->{plottitle} . "\n" . time_descr(), - -rectangle => '1 1 6 6', + -rectangle => '2 1 7 6', -yscaletype => 'categories', -xstackfields => '2', }; From gall at switch.ch Wed Dec 5 16:36:31 2007 From: gall at switch.ch (Alexander Gall) Date: Wed, 5 Dec 2007 17:36:31 +0100 Subject: [dsc] Patch for build on Solaris9 and multiple interfaces fix Message-ID: <18262.54159.79102.802537@hadron.switch.ch> I have used the attached patch to build the DSC collector (version 200706121022) on Solaris 9. The header file fixes are trivial, but I discovered a bug that affects capturing on multiple interfaces. I think this also solves the issue "Multiple interfaces" reported on this list in November (I just joined the list and had a quick look in the archive). The problem is simply that FD_ISSET checks the original FD set rather than the one returned by select(). The fix is obvious (but one also needs to cover the case when select() returns after a timeout). -- Alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dsc-200706121022.diff URL: From andrew.ruthven at catalyst.net.nz Wed Dec 5 21:16:01 2007 From: andrew.ruthven at catalyst.net.nz (Andrew Ruthven) Date: Thu, 06 Dec 2007 10:16:01 +1300 Subject: [dsc] IPv6 on some graphs have issues In-Reply-To: <20071204174156.F16210@measurement-factory.com> References: <1196709609.2927.3.camel@dirk.catalyst.net.nz> <20071204174156.F16210@measurement-factory.com> Message-ID: <1196889361.16312.18.camel@dirk.catalyst.net.nz> Hi Duane, On Tue, 2007-12-04 at 17:42 -0700, Duane Wessels wrote: > > Let me know if this change gives enough room for all those v6 addrs: [patch snipped] Yes, that gives enough room for them. Thanks! -- Andrew Ruthven, Wellington, New Zealand At work: andrew.ruthven at catalyst.net.nz At home: andrew at etc.gen.nz GPG fpr: 34CA 12A3 C6F8 B156 72C2 D0D7 D286 CE0C 0C62 B791 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From gall at switch.ch Thu Dec 6 16:21:01 2007 From: gall at switch.ch (Alexander Gall) Date: Thu, 6 Dec 2007 17:21:01 +0100 Subject: [dsc] DNS IP version indexer Message-ID: <18264.8557.277469.155895@hadron.switch.ch> I've written an indexer for the IP version of DNS messages. There already is an IP indexer called ip_version, so I named this one dns_ip_version. I have also created a dataset called dns_ip_version_vs_qtype, because it could be interesting to see whether the query type distribution is different for the two address families. This is the dataset definition I use on the collector: dataset dns_ip_version_vs_qtype dns IPVersion:dns_ip_version Qtype:qtype queries-only; On the presenter, there is one time-sequence graph for the IP version just like "DNS Transport". The sub-graph "IP Version/Query Types" is not really useful as it is, because the amount of queries over IPv6 is so small. There might be a better way to present this data, e.g. scale it relative to the number of queries per address family (not the total amount of queries), but I don't think this is possible in a single graph. -- Alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dsc-collector.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dsc-presenter.diff URL: From dikshie at lapi.itb.ac.id Wed Dec 12 04:52:48 2007 From: dikshie at lapi.itb.ac.id (Dikshie) Date: Wed, 12 Dec 2007 11:52:48 +0700 Subject: [dsc] gcc problem? Message-ID: <20071212045248.GA29182@lapi.itb.ac.id> Hi, i use old gcc: -------- Using builtin specs gcc version 2.95.4 20020320 [FreeBSD] ------- i got hit by in collector by: cc -g -Wall -DUSE_IPV6=1 -I ../TmgBase/Hapy/src/include -c pcap.c pcap.c:152: field `buf' has incomplete type pcap.c:160: filed `buf' has incomplete type is that gcc issue/problem? regards, -dikshie- From wessels at measurement-factory.com Wed Dec 12 21:10:56 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Wed, 12 Dec 2007 14:10:56 -0700 (MST) Subject: [dsc] gcc problem? In-Reply-To: <20071212045248.GA29182@lapi.itb.ac.id> References: <20071212045248.GA29182@lapi.itb.ac.id> Message-ID: <20071212140903.Q34008@measurement-factory.com> On Wed, 12 Dec 2007, Dikshie wrote: > Hi, > i use old gcc: > -------- > Using builtin specs > gcc version 2.95.4 20020320 [FreeBSD] > ------- > > i got hit by in collector by: > > cc -g -Wall -DUSE_IPV6=1 -I ../TmgBase/Hapy/src/include -c pcap.c > pcap.c:152: field `buf' has incomplete type > pcap.c:160: filed `buf' has incomplete type > > is that gcc issue/problem? I'm guessing that it is these lines?: u_char buf[]; /* reassembled message (C99 flexible array member) */ .... u_char buf[]; /* segment payload (C99 flexible array member) */ My guess is that older gcc is not familiar with this syntax. If you can't upgrade your gcc, then you could try changing those lines to say: u_char *buf; Duane W. From fw at deneb.enyo.de Wed Dec 12 21:19:00 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 12 Dec 2007 22:19:00 +0100 Subject: [dsc] gcc problem? In-Reply-To: <20071212140903.Q34008@measurement-factory.com> (Duane Wessels's message of "Wed, 12 Dec 2007 14:10:56 -0700 (MST)") References: <20071212045248.GA29182@lapi.itb.ac.id> <20071212140903.Q34008@measurement-factory.com> Message-ID: <87mysf1uij.fsf@mid.deneb.enyo.de> * Duane Wessels: > On Wed, 12 Dec 2007, Dikshie wrote: > >> Hi, >> i use old gcc: >> -------- >> Using builtin specs >> gcc version 2.95.4 20020320 [FreeBSD] >> ------- >> >> i got hit by in collector by: >> >> cc -g -Wall -DUSE_IPV6=1 -I ../TmgBase/Hapy/src/include -c pcap.c >> pcap.c:152: field `buf' has incomplete type >> pcap.c:160: filed `buf' has incomplete type >> >> is that gcc issue/problem? > > I'm guessing that it is these lines?: > > u_char buf[]; /* reassembled message (C99 flexible array member) */ > .... > u_char buf[]; /* segment payload (C99 flexible array member) */ > > My guess is that older gcc is not familiar with this syntax. If you can't > upgrade your gcc, then you could try changing those lines to say: > > u_char *buf; Actually, that should be: u_char buf[0]; Using a pointer instead will lead to crashes. From avinesh_joshi at rediffmail.com Thu Dec 13 06:30:17 2007 From: avinesh_joshi at rediffmail.com (Avinesh Joshi) Date: 13 Dec 2007 06:30:17 -0000 Subject: [dsc] collector compilation error in solaris Message-ID: <20071213063017.28238.qmail@webmail47.rediffmail.com> ?I am using solaris 8 with gcc 3.4.6 . After applying patch for solaris by Alexander Gall i am getting follwing error while running make for collector make (cd dsc; make all) o dsc base64.o generic_counter.o pcap.o dns_protocol.o dns_message.o ip_message.o daemon.o md_array.o null_index.o qtype_index.o qclass_index.o tld_index.o rcode_index.o qnamelen_index.o qname_index.o msglen_index.o client_ipv4_addr_index.o client_ipv4_net_index.o md_array_xml_printer.o ip_direction_index.o ip_proto_index.o ip_version_index.o certain_qnames_index.o query_classification_index.o idn_qname_index.o edns_version_index.o do_bit_index.o rd_bit_index.o opcode_index.o transport_index.o ParseConfig.o config_hooks.o hashtbl.o lookup3.o xmalloc.o inX_addr.o -lpcap ../TmfBase/Hapy/src/.libs/libHapy.a sh: o: not found *** Error code 1 (ignored) Regard's Avinesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From wessels at measurement-factory.com Thu Dec 13 17:46:13 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Thu, 13 Dec 2007 10:46:13 -0700 (MST) Subject: [dsc] collector compilation error in solaris In-Reply-To: <20071213063017.28238.qmail@webmail47.rediffmail.com> References: <20071213063017.28238.qmail@webmail47.rediffmail.com> Message-ID: <20071213104427.N34008@measurement-factory.com> On Wed, 13 Dec 2007, Avinesh Joshi wrote: > ?I am using solaris 8 with gcc 3.4.6 . After applying patch for solaris by Alexander Gall i am getting follwing error while running make for collector > > > make > (cd dsc; make all) > o dsc base64.o generic_counter.o pcap.o ... > ... > sh: o: not found > *** Error code 1 (ignored) Looks like your 'make' environment does not define the $CXX variable, so this line is failing: $(PROG): $(OBJS) $(LIBHAPY) $(CXX) -o $@ $(OBJS) $(LDFLAGS) $(LIBS) You can try changing CXX to CC. If that doesn't work, then try changing $(CXX) to g++ or gcc. Duane W. From avinesh_joshi at rediffmail.com Fri Dec 14 07:22:08 2007 From: avinesh_joshi at rediffmail.com (Avinesh Joshi) Date: 14 Dec 2007 07:22:08 -0000 Subject: [dsc] collector compilation error in solaris Message-ID: <20071214072208.7897.qmail@webmail66.rediffmail.com> ? Hi, After changing it to g++ i am getting following error g++ -o dsc base64.o generic_counter.o pcap.o dns_protocol.o dns_message.o ip_message.o daemon.o md_array.o null_index.o qtype_index.o qclass_index.o tld_index.o rcode_index.o qnamelen_index.o qname_index.o msglen_index.o client_ipv4_addr_index.o client_ipv4_net_index.o md_array_xml_printer.o ip_direction_index.o ip_proto_index.o ip_version_index.o certain_qnames_index.o query_classification_index.o idn_qname_index.o edns_version_index.o do_bit_index.o rd_bit_index.o opcode_index.o transport_index.o ParseConfig.o config_hooks.o hashtbl.o lookup3.o xmalloc.o inX_addr.o -lpcap ../TmfBase/Hapy/src/.libs/libHapy.a -lsocket -lnsl Undefined first referenced symbol in file inet_aton query_classification_index.o ld: fatal: Symbol referencing errors. No output written to dsc collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `dsc' Regard's Avinesh Note: Forwarded message attached -- Original Message -- From: Duane Wessels To: Avinesh Joshi Cc: dsc at measurement-factory.com Subject: Re: [dsc] collector compilation error in solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Duane Wessels Subject: Re: [dsc] collector compilation error in solaris Date: no date Size: 1337 URL: From gall at switch.ch Fri Dec 14 08:23:25 2007 From: gall at switch.ch (Alexander Gall) Date: Fri, 14 Dec 2007 09:23:25 +0100 Subject: [dsc] collector compilation error in solaris In-Reply-To: <20071214072208.7897.qmail@webmail66.rediffmail.com> References: <20071214072208.7897.qmail@webmail66.rediffmail.com> Message-ID: <18274.15741.722521.97667@hadron.switch.ch> On 14 Dec 2007 07:22:08 -0000, "Avinesh Joshi" said: > ? > After changing it to g++ i am getting following error > g++ -o dsc base64.o generic_counter.o pcap.o dns_protocol.o dns_message.o ip_message.o daemon.o md_array.o null_index.o qtype_index.o qclass_index.o tld_index.o rcode_index.o qnamelen_index.o qname_index.o msglen_index.o client_ipv4_addr_index.o client_ipv4_net_index.o md_array_xml_printer.o ip_direction_index.o ip_proto_index.o ip_version_index.o certain_qnames_index.o query_classification_index.o idn_qname_index.o edns_version_index.o do_bit_index.o rd_bit_index.o opcode_index.o transport_index.o ParseConfig.o config_hooks.o hashtbl.o lookup3.o xmalloc.o inX_addr.o -lpcap ../TmfBase/Hapy/src/.libs/libHapy.a -lsocket -lnsl > Undefined first referenced > symbol in file > inet_aton query_classification_index.o > ld: fatal: Symbol referencing errors. No output written to dsc > collect2: ld returned 1 exit status > *** Error code 1 > make: Fatal error: Command failed for target `dsc' inet_aton is in a different library on Solaris 8/9. You need to add -lresolv to LDFLAGS. -- Alex From avinesh_joshi at rediffmail.com Fri Dec 14 11:03:11 2007 From: avinesh_joshi at rediffmail.com (Avinesh Joshi) Date: 14 Dec 2007 11:03:11 -0000 Subject: [dsc] collector compilation error in solaris Message-ID: <20071214110311.6336.qmail@webmail8.rediffmail.com> after putting -lresolv make is successfull but when i run make install i get the following error ? make install (cd dsc; make install) ../TmfBase/Hapy/src/.libs/libHapy.a is out of date cd ../TmfBase/Hapy; make all Making all in src Making all in doc Making all in tests installing in install -d -m 755 /usr/local/dsc/bin/ install -d -m 755 /usr/local/dsc/etc/ install -d -m 755 /usr/local/dsc/var/ install -d -m 755 /usr/local/dsc/var/log/ install -m 755 dsc /usr/local/dsc/bin/ install: dsc was not found anywhere! *** Error code 2 make: Fatal error: Command failed for target `install' Current working directory /dns-stat/dsc-200706121022/collector/dsc *** Error code 1 make: Fatal error: Command failed for target `install' Regard's Avinesh On Fri, 14 Dec 2007 Alexander Gall wrote : >On 14 Dec 2007 07:22:08 -0000, "Avinesh Joshi" said: > > > > > After changing it to g++ i am getting following error > > g++ -o dsc base64.o generic_counter.o pcap.o dns_protocol.o dns_message.o ip_message.o daemon.o md_array.o null_index.o qtype_index.o qclass_index.o tld_index.o rcode_index.o qnamelen_index.o qname_index.o msglen_index.o client_ipv4_addr_index.o client_ipv4_net_index.o md_array_xml_printer.o ip_direction_index.o ip_proto_index.o ip_version_index.o certain_qnames_index.o query_classification_index.o idn_qname_index.o edns_version_index.o do_bit_index.o rd_bit_index.o opcode_index.o transport_index.o ParseConfig.o config_hooks.o hashtbl.o lookup3.o xmalloc.o inX_addr.o -lpcap ../TmfBase/Hapy/src/.libs/libHapy.a -lsocket -lnsl > > Undefined first referenced > > symbol in file > > inet_aton query_classification_index.o > > ld: fatal: Symbol referencing errors. No output written to dsc > > collect2: ld returned 1 exit status > > *** Error code 1 > > make: Fatal error: Command failed for target `dsc' > >inet_aton is in a different library on Solaris 8/9. You need to add >-lresolv to LDFLAGS. > >-- >Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wessels at measurement-factory.com Fri Dec 14 20:44:02 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Fri, 14 Dec 2007 13:44:02 -0700 (MST) Subject: [dsc] collector compilation error in solaris In-Reply-To: <20071214110311.6336.qmail@webmail8.rediffmail.com> References: <20071214110311.6336.qmail@webmail8.rediffmail.com> Message-ID: <20071214134238.Q76935@measurement-factory.com> On Fri, 14 Dec 2007, Avinesh Joshi wrote: > after putting -lresolv make is successfull but when i run make install > i get the following error > ? > make install > (cd dsc; make install) > ../TmfBase/Hapy/src/.libs/libHapy.a is out of date > cd ../TmfBase/Hapy; make all > Making all in src > Making all in doc > Making all in tests > installing in > install -d -m 755 /usr/local/dsc/bin/ > install -d -m 755 /usr/local/dsc/etc/ > install -d -m 755 /usr/local/dsc/var/ > install -d -m 755 /usr/local/dsc/var/log/ > install -m 755 dsc /usr/local/dsc/bin/ > install: dsc was not found anywhere! > *** Error code 2 looks like the 'dsc' program did not get fully created for some reason. What happens if you do this: $ cd collectors/dsc $ rm -f dsc $ make dsc $ make install DW From wessels at measurement-factory.com Fri Dec 14 21:19:08 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Fri, 14 Dec 2007 14:19:08 -0700 (MST) Subject: [dsc] DNS IP version indexer In-Reply-To: <18264.8557.277469.155895@hadron.switch.ch> References: <18264.8557.277469.155895@hadron.switch.ch> Message-ID: <20071214141846.W76935@measurement-factory.com> On Thu, 6 Dec 2007, Alexander Gall wrote: > > I've written an indexer for the IP version of DNS messages. There > already is an IP indexer called ip_version, so I named this one > dns_ip_version. Thanks! This has been committed to the source repository. Duane W. From wessels at measurement-factory.com Fri Dec 14 21:41:02 2007 From: wessels at measurement-factory.com (Duane Wessels) Date: Fri, 14 Dec 2007 14:41:02 -0700 (MST) Subject: [dsc] Patch for build on Solaris9 and multiple interfaces fix In-Reply-To: <18262.54159.79102.802537@hadron.switch.ch> References: <18262.54159.79102.802537@hadron.switch.ch> Message-ID: <20071214143531.R76935@measurement-factory.com> On Wed, 5 Dec 2007, Alexander Gall wrote: > > I have used the attached patch to build the DSC collector (version > 200706121022) on Solaris 9. The header file fixes are trivial, but I > discovered a bug that affects capturing on multiple interfaces. I > think this also solves the issue "Multiple interfaces" reported on > this list in November (I just joined the list and had a quick look in > the archive). > > The problem is simply that FD_ISSET checks the original FD set rather > than the one returned by select(). The fix is obvious (but one also > needs to cover the case when select() returns after a timeout). Hi Alex, I've applied your #include changes for Solaris, thanks. The current select() behavior is intentional. There is an oldish known problem on some operating systems where they don't always set the FD for reading. The suggested workaround is to always try reading from the pcap whenever select returns. See http://www.tcpdump.org/lists/workers/2002/09/msg00033.html That message *is* five years old, so maybe this is no longer a problem with current pcap implementations. If anyone knows for sure then we could try doing it the "right" way. But I also believe that the workaround doesn't create any significant performance penalties. I also recently discovered and fixed a bug with multiple interfaces. I found that if you have interfaces with differnt pcap datalink types, then only the last one would be read. I found it by trying to read from both loopback and a physical interface. Now DSC stores the datalink handler function with each pcap. DW From gall at switch.ch Mon Dec 17 10:17:18 2007 From: gall at switch.ch (Alexander Gall) Date: Mon, 17 Dec 2007 11:17:18 +0100 Subject: [dsc] Patch for build on Solaris9 and multiple interfaces fix In-Reply-To: <20071214143531.R76935@measurement-factory.com> References: <18262.54159.79102.802537@hadron.switch.ch> <20071214143531.R76935@measurement-factory.com> Message-ID: <18278.19630.878893.10303@hadron.switch.ch> Hello Duane, On Fri, 14 Dec 2007 14:41:02 -0700 (MST), Duane Wessels said: > On Wed, 5 Dec 2007, Alexander Gall wrote: >> >> I have used the attached patch to build the DSC collector (version >> 200706121022) on Solaris 9. The header file fixes are trivial, but I >> discovered a bug that affects capturing on multiple interfaces. I >> think this also solves the issue "Multiple interfaces" reported on >> this list in November (I just joined the list and had a quick look in >> the archive). >> >> The problem is simply that FD_ISSET checks the original FD set rather >> than the one returned by select(). The fix is obvious (but one also >> needs to cover the case when select() returns after a timeout). > The current select() behavior is intentional. There is an oldish > known problem on some operating systems where they don't always set > the FD for reading. The suggested workaround is to always try > reading from the pcap whenever select returns. See > http://www.tcpdump.org/lists/workers/2002/09/msg00033.html I see. > That message *is* five years old, so maybe this is no longer a > problem with current pcap implementations. If anyone knows for > sure then we could try doing it the "right" way. But I also believe > that the workaround doesn't create any significant performance > penalties. Performance was not the problem, I think, but I've had problems with dual-homed name servers on Solaris and Linux dropping most of the captured packets anyway. Two of them are getting around 700 queries per second peak load and one about 1200 qps. On all of them, DSC with the original code only registered on the order of a few ten queries per second. I could increase that to maybe one or two hundred qps by playing with the timeout value in the pcap_dispatch() call, but most of the packets were still dropped somewhere. For Solaris, I suspect that the drops occured somewhere in the STREAMS module chain, e.g. when libpcap is waiting too long on a file descriptor that hasn't got any packets, the queue of the other fd is overflowing (STREAMS buffers appear to be quite small, like 64KiB or so). I'm not really sure, though. I'm currently using my patch on Solaris 9 and Linux 2.6.12. It works perfectly on those systems, so they appear to handle select() on libpcap file descriptors correctly. I think it would make sense to do it "the right way" on these OSs. > I also recently discovered and fixed a bug with multiple interfaces. > I found that if you have interfaces with differnt pcap datalink > types, then only the last one would be read. I found it by trying > to read from both loopback and a physical interface. Now DSC stores > the datalink handler function with each pcap. OK. In my case, all interfaces are of the same datalink types. -- Alex From gall at switch.ch Tue Dec 18 16:21:35 2007 From: gall at switch.ch (Alexander Gall) Date: Tue, 18 Dec 2007 17:21:35 +0100 Subject: [dsc] IP version filter Message-ID: <18279.62351.451817.14420@hadron.switch.ch> I'd like to have separate client statistics for IPv4 and IPv6. I've added filters to select the IP version used to transport a DNS message called 'ipv4' and 'ipv6'. To start with, I've added two sub-graphs to the "Rcodes by Client Address" graph, showing each address family separately. They are generated from two new datasets called client_addr_ipv{4,6}_vs_rcode in addition to client_addr_vs_rcode (which holds both address families): dataset client_addr_vs_rcode dns Rcode:rcode ClientAddr:client replies-only max-cells=50; dataset client_addr_ipv4_vs_rcode dns Rcode:rcode ClientAddr:client replies-only,ipv4 max-cells=50; dataset client_addr_ipv6_vs_rcode dns Rcode:rcode ClientAddr:client replies-only,ipv6 max-cells=50; The "Classification" and "Client Geography" graphs require a bit more work. Most IPv6 addresses are too wide and are cut off at the left margin of the graphs. I haven't tried to fix that yet. The attached patches for the collector and the presenter include some of the stuff I've posted earlier. -- Alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: collector.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: presenter.diff URL: