Hi Harald,
I realise this may not be convenient for you, but what I have done a couple of times is to have a private dissector parse logging frames in the same capture that contain info about new SAs being created. With all of the relevant information in hand, the dissector then calls esp_sa_record_add_from_dissector().
Note that these entries are not added to the UAT table, and that any entries added in this way are matched *before* any competing UAT entries.
Regards,
Martin
Sorry if this has been covered before, but I could only find several
locations online where the question has been asked, but no response anywhere:
Is there already a mechanism by which a running wireshark can be triggered to
re-load UAT tables at runtime, in my specific use case those for IKEv2 and ESP SA?
I tried to grep for uat_load in the source but couldn't find any specific
externally-triggered place other than doing a manual change and then pressing
the cancel button, which will do a uat_load().
I guess it should be relatively simple to add at least something like a SIGHUP
or SIGUSR1 handler which would trigger the reload of the tables? The proper/fancy
approach on Linux would of course be to use inotify/dnotfiy to get a notification
from the kernel whenever some external program has updated those tables.
The use case, in case it's not obvious, is to use an IPsec implementation that
has been instrumented to update those tables automatically "in real-time" as new
IKE handshakes or SAs are established. This is alerady possible e.g. from strongswan
with a related plugin.
Saving a pcap and opening it later on is of course always possible, but it seems
rather clumsy to me, if there's no good reason against the good old "signal to re-read
config files" approach.
Thanks for your input,
Harald
--
- Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe