FYI, starting with 10.4, you can bypass the query and just pass a where clause to the packets command. It will do the query for you on the backend and send back only the packets that match the query:
http://<hostname and port>/sdk/packets?where=ip.src%3D10.194.238.251
Of course, the where clause can be as complicated as any regular query. This also works with the new 10.4 content search capability "msearch", which let's you search words (or regex) in packets or logs and returns the hits. This command returns the same results as the older /sdk search command, but works over many sessions or a query to provide low latency. It can search over raw packets/logs or over the list of meta for each session or both (see flags).
Here's are the parameters used by the command:
msearch: Search for pattern matches in many sessions or packets
security.roles: sdk.content & sdk.meta
parameters:
sessions - <string, optional> The session ID ranges to search
packets - <string, optional> The packet ID ranges to search
search - <string> The search string to use
where - <string, optional> The where clause used to identify sessions to consider for the search
limit - <uint64, optional> The maximum number of sessions to traverse for this search
flags - <string, optional> Flags to use for search. This is a comma separated list of one or more of the flag values regex, sp, sm, ci, pre, post, ds, precache
Here's what the flags mean:
1) regex means the search parameter is a regular expression. Otherwise it is treated as a normal search string
2) sp means search packets or logs. Raw data search.
3) sm means search meta
4) ci means do the search case insensitive
5) pre means return data prior (characters before) the search hit. In other words, provides context to the data found
5) post means return data after (characters after) the search hit. Used for displaying context to the search hit
6) ds means decode session. So, on a packet session, if you were searching an email, all base64 attachments would be decoded to regular files before being searched. This works over all service types that we have native decoding support (pop, smtp, http, smb, ftp, etc).
7) precache means it will attempt to speed up the content search by making periodic precache calls to upstream decoders before calling msearch on them. Generally speaking, there's no harm in always passing this flag and when it works well, it can greatly speed up the searches.
The search string can be a regex (depends on what's passed in flags) or it can be a simple text search. The text search provides these capabilities:
1) Each whitespace delimited word is ANDed, so everything must match. For instance search="glazed donut", both glazed and donut must be found in the session (they don't have to be together or in any specific order).
2) The word OR is special, so search="glazed OR donut" means either glazed or donut must be found in the session to match, both are not required. OR must be capitalized. "or" will just look for the word or.
3) You can mix or match implicit ands and ORs together in the search string. The explicit OR has higher precedence than then implicit (whitespace) AND demonstrated as follows:
'cheese toast OR bread dumplings' is the same is the logical statement 'cheese AND (toast OR bread) AND dumplings'
This would require that both the terms 'cheese' and 'dumplings be present in a match and one of 'toast' or 'bread'
4) Words can be exclude from search results using the '-' operator:
'cheese -toast'
This would return any result that has the word 'cheese' unless the word 'toast' is also present.
5) Words will match any exactly matching substring within a session's content (e.g. 'each' is found in 'beach').
The results are streamed back in real time as they are found. Over the REST interface, this will be via chunked-encoding.
