Hi Brent, Thanks very much for the feedback. I've just corrected the issue and will commit it to the CVS shortly later today.
Cheers, Paolo On Thu, Mar 11, 2010 at 09:26:57AM -0800, Brent Van Dussen wrote: > Paolo - > > Just tried to build the latest CVS version and am getting compile errors > when configure option "--disable-l2" is used. When I re-configured > without it everything builds fine. > > Here's the error I get: > > -bash-3.2$ make > Making all in src > gmake[1]: Entering directory `/home/bvd/pmacct-cvs/pmacct/src' > Making all in nfprobe_plugin > gmake[2]: Entering directory `/home/bvd/pmacct-cvs/pmacct/src/ > nfprobe_plugin' > gcc -DPACKAGE=\"pmacctd\" -DVERSION=\"0.12.1-cvs\" -DPROGNAME=1 - > DIM_LITTLE_ENDIAN=1 -DHAVE_PCAP_H=1 -DHAVE_LIBPCAP=1 -DPCAP_7=1 - > DPCAP_TYPE_linux=1 -DHAVE_DLOPEN=1 -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1 > -DHAVE_GETOPT_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_TIME_H=1 > -DHAVE_U_INT64_T=1 -DHAVE_U_INT32_T=1 -DHAVE_U_INT16_T=1 > -DHAVE_U_INT8_T=1 -DENABLE_THREADS=1 -DRETSIGTYPE=void -DHAVE_VSNPRINTF=1 > -I. -I.. -O2 -DFLOW_SPLAY -DEXPIRY_RB -c -o > nfprobe_plugin.o > nfprobe_plugin.c > nfprobe_plugin.c: In function ???l2_to_flowrec???: > nfprobe_plugin.c:312: error: ???p??? undeclared (first use in this > function) > nfprobe_plugin.c:312: error: (Each undeclared identifier is reported > only once > nfprobe_plugin.c:312: error: for each function it appears in.) > gmake[2]: *** [nfprobe_plugin.o] Error 1 > gmake[2]: Leaving directory `/home/bvd/pmacct-cvs/pmacct/src/ > nfprobe_plugin' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/bvd/pmacct-cvs/pmacct/src' > make: *** [all-recursive] Error 1 > > Should be able to let you know shortly how the prefix length feature > works. > > Thanks, > -Brent > > On Mar 9, 2010, at 8:28 AM, Brent Van Dussen wrote: > >> Thanks for getting this set up Paolo! >> >> We'll get the latest CVS version loaded and tested this week to >> provide feedback. >> >> Cheers, >> -Brent >> >> On Mar 7, 2010, at 1:34 AM, Paolo Lucente wrote: >> >>> Hi Brent, All, >>> >>> On Sat, Feb 20, 2010 at 01:05:20AM +0000, Paolo Lucente wrote: >>> >>>>> Would it also be possible to have the dst_net appended with mask >>>>> length >>>>> and a slightly larger DB field to accomodate it? >>>>> 255.255.255.255/25 >>>>> would be a CHAR(18) instead of CHAR(15) but it would be really >>>>> nice to >>>>> have this information from BGP or the sflow prefix field added in >>>>> so a >>>>> network map isn't needed. >>>> >>>> Netmasks. They are not there but i've recently received two more >>>> requests in a row for such a feature. All coming from people making >>>> use of the BGP feature. Hence, this is on my todo list and will >>>> appear very soon - would say roughly 3-4 weeks. Would such approx >>>> timeline match your expectations? >>> >>> To say at this propo that network masks have now been implemented >>> as aggregation primitives. It's all published in the CVS. Network >>> masks lie in a different field from the IP prefix - so that this >>> implementation can get handy for other, ie. statistical, purposes. >>> Indeed, SQL language manipulation can be used to merge masks and >>> IP prefixes together on output. >>> >>> Also, good property of this way of proceeding is that by keeping >>> masks in a separate field, they can be defined as INT(1) which is >>> space-savy compared to a string representation within the IP prefix >>> field. I already see this argument will not particularly impress >>> the PosgreSQL friends but it's done for the sake of selecting a >>> generic approach (not all RDBMS packages have the luxury of 'inet' >>> types ...). >>> >>> Cheers, >>> Paolo >>> >>> >>> _______________________________________________ >>> pmacct-discussion mailing list >>> http://www.pmacct.net/#mailinglists >> >> >> _______________________________________________ >> pmacct-discussion mailing list >> http://www.pmacct.net/#mailinglists > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
