[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-dev
Subject: Re: [Wireshark-dev] re-load IKEv2 / ESP UAT during wireshark gui runtime
From: Martin Mathieson via Wireshark-dev <wireshark-dev () wireshark ! org>
Date: 2021-08-19 14:23:45
Message-ID: CAC803ufmw9qxUxnBHy86+B_UTX4yEG0ZBS+_LJsdsY-NPEUU+A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi Harald,<div><br></div><div>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().</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Martin</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 19, 2021 at 12:30 \
PM Harald Welte <<a \
href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry if this has been \
covered before, but I could only find several<br> locations online where the question \
has been asked, but no response anywhere:<br> <br>
Is there already a mechanism by which a running wireshark can be triggered to<br>
re-load UAT tables at runtime, in my specific use case those for IKEv2 and ESP \
SA?<br> <br>
I tried to grep for uat_load in the source but couldn't find any specific<br>
externally-triggered place other than doing a manual change and then pressing<br>
the cancel button, which will do a uat_load().<br>
<br>
I guess it should be relatively simple to add at least something like a SIGHUP<br>
or SIGUSR1 handler which would trigger the reload of the tables? The \
proper/fancy<br> approach on Linux would of course be to use inotify/dnotfiy to get a \
notification<br> from the kernel whenever some external program has updated those \
tables.<br> <br>
The use case, in case it's not obvious, is to use an IPsec implementation \
that<br> has been instrumented to update those tables automatically "in \
real-time" as new<br> IKE handshakes or SAs are established. This is alerady \
possible e.g. from strongswan<br> with a related plugin.<br>
<br>
Saving a pcap and opening it later on is of course always possible, but it seems<br>
rather clumsy to me, if there's no good reason against the good old "signal \
to re-read<br> config files" approach.<br>
<br>
Thanks for your input,<br>
Harald<br>
-- <br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" \
target="_blank">laforge@gnumonks.org</a>> <a \
href="http://laforge.gnumonks.org/" rel="noreferrer" \
target="_blank">http://laforge.gnumonks.org/</a><br> \
============================================================================<br> \
"Privacy in residential applications is a desirable marketing \
option."<br>
(ETSI EN \
300 175-7 Ch. A6)<br> \
___________________________________________________________________________<br> Sent \
via: Wireshark-dev mailing list <<a href="mailto:wireshark-dev@wireshark.org" \
target="_blank">wireshark-dev@wireshark.org</a>><br>
Archives: <a href="https://www.wireshark.org/lists/wireshark-dev" \
rel="noreferrer" target="_blank">https://www.wireshark.org/lists/wireshark-dev</a><br>
Unsubscribe: <a href="https://www.wireshark.org/mailman/options/wireshark-dev" \
rel="noreferrer" target="_blank">https://www.wireshark.org/mailman/options/wireshark-dev</a><br>
mailto:<a href="mailto:wireshark-dev-request@wireshark.org" \
target="_blank">wireshark-dev-request@wireshark.org</a>?subject=unsubscribe<br> \
</blockquote></div>
[Attachment #6 (text/plain)]
___________________________________________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic