Re: [pmacct-discussion] Only meaningful custom primitives should pick the value
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
Re: [pmacct-discussion] Only meaningful custom primitives should pick the value
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
Re: [pmacct-discussion] Only meaningful custom primitives should pick the value
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
[pmacct-discussion] Only meaningful custom primitives should pick the value
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