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 +0000, 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

Reply via email to