Fix Homer search: correct src/dst IP field map + add Type selector#7
Open
simllll wants to merge 3 commits into
Open
Fix Homer search: correct src/dst IP field map + add Type selector#7simllll wants to merge 3 commits into
simllll wants to merge 3 commits into
Conversation
added 3 commits
May 11, 2026 22:55
Two bugs in `/homer` search wired the dashboard against the wrong slice of Homer 7's schema, making whole categories of search return 0 rows even when matching data clearly existed in the DB. 1. Source/Destination IP filters always returned 0 rows `_build_homer_filters` mapped `source_ip` / `dst_ip` to `data_header.src_ip` / `data_header.dst_ip`. Homer 7 stores L3 addresses under `protocol_header.srcIp` / `protocol_header.dstIp` (camelCase), while `data_header` only holds SIP-parsed fields (callid, from_user, method, ...). Filtering on the wrong JSONB column silently returns no rows. Notably, this file's own result rendering elsewhere already reads `srcIp`/`dstIp` — so the same module wrote one path and read another. Fixed the field map to match where the data actually lives. 2. REGISTER / OPTIONS / MESSAGE etc. were unsearchable The search request hard-coded `protocol_profile: "call"`, which pins the query to `hep_proto_1_call`. Homer 7 splits SIP into three tables by transaction type: `_call` (INVITE/BYE/CANCEL/...), `_registration` (REGISTER), and `_default` (OPTIONS/MESSAGE/...). `method=REGISTER` against the call table is always empty even when REGISTER traffic is being captured fine. Added a `Type` dropdown (Call / Registration / Other) plumbed through routes → service → Homer payload. Defaults to `call` so existing bookmarks behave unchanged. Also skips the unbounded call/transaction callid-shortcut for non-call profiles since that endpoint is call-table-specific. Tested by submitting searches with each Type + IP filters against a Homer 7 deployment ingesting from heplify; rows come back for each case that previously returned nothing.
PR thinhdanggroup#7 made search work for REGISTER / OPTIONS / MESSAGE traffic, but clicking a row in the result table still rendered an empty flow diagram. Same root cause as the search bug, in the *detail* path this time: `get_call_transaction` hard-coded both the transaction flags and the search-key prefix to "call", so any callid lookup queried `hep_proto_1_call` regardless of which table the row actually lived in. payload["param"]["transaction"] = {"call": True, "registration": False, "rest": False} payload["param"]["search"] = {"1_call": ...} For a REGISTER callid the call table has no messages → Homer returns zero rows → `_build_call_detail` produces an empty `messages`/`flow_rows` list → the ladder diagram renders blank. Plumb the profile through: - `get_call_transaction` accepts `profile` (default "call"), maps it to the matching transaction-flag triple, and uses `1_{profile}` in the search key. - `HomerClient.get_call_transaction` accepts profile. - `homer_call_detail` / `homer_call_export` routes accept a `profile` query param and forward it. - Result-row links in `homer/index.html.j2` and the export link in `homer/call.html.j2` carry `&profile={{ profile }}` so the detail view inherits the search's profile rather than guessing. Defaults remain "call" so existing call-profile bookmarks and old links keep working unchanged.
Tab nav hrefs in homer/call.html.j2 rebuilt the query string from record_id/ts/tab only, so clicking Flow/Messages/Session/Logs/Export dropped the `profile` param the search-result link had supplied. The detail route then fell back to the default `call` profile and queried the wrong transaction table — REGISTERs went back to rendering as an empty flow diagram on every tab switch. Include `profile` in all five tab hrefs alongside record_id/ts/tab.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two bugs in the
/homersearch route silently dropped whole categories of search results because the request was wired against the wrong slice of Homer 7's schema.1. Source / Destination IP filters always returned 0 rows
_build_homer_filtersmappedsource_ip/dst_ipto:But Homer 7 stores L3 addresses under
protocol_header.srcIp/protocol_header.dstIp(camelCase).data_headeronly holds SIP-parsed fields (callid,from_user,method, …). Filtering on the wrong JSONB column silently returns nothing.Notably, this file's own result rendering in
app/routes/homer.pyalready readssrcIp/dstIp:— so the same module was writing the filter as one path and reading the result back from another. Fixed the field map to match where the data actually lives.
2. REGISTER / OPTIONS / MESSAGE etc. were unsearchable
The search request hard-coded the protocol profile:
This pins the query to
hep_proto_1_call. Homer 7 splits SIP into three tables by transaction type:callhep_proto_1_callregistrationhep_proto_1_registrationdefaulthep_proto_1_defaultmethod=REGISTERagainst the call table is always empty even when REGISTER traffic is being captured fine.Added a
Typedropdown (Call / Registration / Other) plumbed through routes → service → Homer payload. Defaults tocallso existing bookmarks and links behave unchanged. The unboundedcall/transactioncallid shortcut is now skipped for non-call profiles, since that endpoint is call-table-specific.Diff summary
app/services/homer.py_build_homer_filters: fixsource_ip/dst_ipfield mapSUPPORTED_PROFILES,DEFAULT_PROFILE,_normalize_profilesearch_calls/HomerClient.search_calls: acceptprofile, use it forprotocol_profileand thesearchkeyapp/routes/homer.pyprofilequery param tohomer_indexhc.search_calls; skip callid-shortcut for non-call profilesprofile+profile_choicesin template contextapp/templates/homer/index.html.j2<select name="profile">before the Time Range selectTesting
Tested against a Homer 7 deployment ingesting from heplify-server:
?src_ip=<X>now returns rows for any IP that appears in the unfiltered result list (previously empty).?profile=registration&method=REGISTERreturns REGISTER traffic fromhep_proto_1_registration(previously empty).profileomitted) behaves identically to before for call-profile searches.call/transactionendpoint whenprofile=call.Happy to adjust scope or split into two PRs if you'd prefer the IP fix to land separately from the Type selector.