Re: re-load IKEv2 / ESP UAT during wireshark gui runtime

[Martin Mathieson via Wireshark-dev <wireshark-dev () wireshark org>]

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 <laforge () 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 <laforge () 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-request () 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-request () wireshark org?subject=unsubscribe