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 On Thu, Aug 19, 2021 at 12:30 PM Harald Welte <lafo...@gnumonks.org> wrote: > 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 <lafo...@gnumonks.org> > 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@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
