Re: [pmacct-discussion] uninitialized req passed to plugin_requests and load_id_file in pm_pcap_cb??

2020-01-20 Thread Paolo Lucente


Hi Mikhail,

If you see all the daemons that make use of the 'req' structure have a
memset() for 'req' shortly after its declaration. For example here in
pmacctd: https://github.com/pmacct/pmacct/blob/master/src/pmacctd.c#L360

Paolo

On Fri, Jan 17, 2020 at 07:10:13PM +0100, Mikhail Sennikovsky wrote:
> Hi all,
> 
> I was running through the pm_pcap_cb code, and it looks like the "req"
> passed to exec_plugins(&pptrs, &req); at
> https://github.com/pmacct/pmacct/blob/d72440dc9a7d0d0a7ed9502f1dd31b90105b1d95/src/nl.c#L167
> and to load_id_file at
> https://github.com/pmacct/pmacct/blob/d72440dc9a7d0d0a7ed9502f1dd31b90105b1d95/src/nl.c#L179
> and below
> is actually uninitialized. (See struct plugin_requests req;  at
> https://github.com/pmacct/pmacct/blob/d72440dc9a7d0d0a7ed9502f1dd31b90105b1d95/src/nl.c#L51
> )
> Note that the exec_plugins and load_id_file actually read from req
> rather than write to it.
> If I'm getting this right, that code might be working just by coincidence.
> 
> Thanks,
> Mikhail
> 
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists

___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists


Re: [pmacct-discussion] Only meaningful custom primitives should pick the value

2020-01-20 Thread Paolo Lucente


Hi,

You could put the port filter in a pcap_filter and have two pmacctd, one
reading http traffic, one reading dns traffic and each configured to
pick up and export the relevant primitives. Would that work for you?

Paolo

On Fri, Jan 17, 2020 at 11:45:26AM +0530, HEMA CHANDRA YEDDULA wrote:
> Hi,
> 
> Thanks for the prompt reply. I think there is some misinterpretation of the 
> scenario.I'm
> trying to explain it litte more explicitly
> 
>  
> We want to add some primitives defined by us with our PEN value. And the 
> primitives are
> of different protocols like http and dns in same template. In our case 
> httpStatusCode,
> httpRequestHost, dnsType and dnsDomainName are the primitives of interest in 
> our case.
> We have regex based payload processing and payload offset defined for each 
> primitive.
> For suppose if the flow has http request packets then only httpRequestHost 
> should be
> processed and pick the value and the rest of them should be blank. But what 
> happens here
> is httpRequestHost will get desired value and the rest of them picking some 
> junk from
> the offset ptr of size defined through primitive length.
> 
> So, What we were thinking is to perform a check on port number like if dest 
> port is 80
> then only httprequesthost should pick the value and rest should be blank.
> 
> Is there any way to perform this type of check on port number.
> 
> Thanks and Regards,
> Hema Chandra Yeddula
> 
> 
> 
> 
> 
> 
> On Thu, 16 Jan 2020 23:48:04 +, Paolo Lucente wrote
> Hi,
> 
> If you define certain primitives, those not present in the parsed flow
> entry should be indeed left blank. If that is not the case, then it's a
> bug and i'd like to ask you for a way to reproduce the issue (so your
> config along with a brief capture (template + data packets) of your
> data.
> 
> Paolo
> 
> On Wed, Jan 15, 2020 at 04:07:17PM +0530, HEMA CHANDRA YEDDULA wrote:
> > 
> > Hi,
> > 
> > I have a scenario where we are planning to add custom primitives that 
> > includes fields 
> > across different protocols like http_request_host, http_response_code, 
> > sip_request_uri 
> > and sip_status_code. In the existing version, if they are defined to be 
> > picked up from
> > payload, then all four of them pick some value depending on the length 
> > defined. Is there 
> > any way to sense the protocol and only meaningful custom primitives will 
> > pick the value
> > and the rest should be blank. 
> > 
> > Thanks and regards,
> > Hema Chandra
> > 
> > ---
> > ::Disclaimer::
> > ---
> > 
> > The contents of this email and any attachment(s) are confidential and 
> > intended
> > for the named recipient(s) only. It shall not attach any liability on C-DOT.
> > Any views or opinions presented in this email are solely those of the author
> > and  may  not  necessarily  reflect  the  opinions  of  C-DOT.  Any  form of
> > reproduction, dissemination, copying, disclosure, modification, distribution
> > and / or publication of this message without the prior written consent of 
> > the
> > author of this e-mail is strictly prohibited. If you have received this 
> > email
> > in error please delete it and notify the sender immediately.
> > 
> > ---
> > 
> > 
> > ___
> > pmacct-discussion mailing list
> > http://www.pmacct.net/#mailinglists
> 
> ___
> pmacct-discussion mailing list
> http://www.pmacct.net/#mailinglists
> 
> 
> ---
> ::Disclaimer::
> ---
> 
> The contents of this email and any attachment(s) are confidential and intended
> for the named recipient(s) only. It shall not attach any liability on C-DOT.
> Any views or opinions presented in this email are solely those of the author
> and  may  not  necessarily  reflect  the  opinions  of  C-DOT.  Any  form of
> reproduction, dissemination, copying, disclosure, modification, distribution
> and / or publication of this message without the prior written consent of the
> author of this e-mail is strictly prohibited. If you have received this email
> in error please delete it and notify the sender immediately.
> 
> ---
> 

___
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists