Idea for synchonous logging/review of debug + GSMTAP

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Jan 30 12:18:49 UTC 2013


Hi Jolly,

On Wed, Jan 30, 2013 at 07:57:54AM +0100, jolly wrote:
> as you said, the target should have header fields for logging catergory
> and level, so one can filter individually. there should be also a field
> which flags the logging messages that are actually displayed on the
> screen (filtered by the application), so one does not need to select the
> same filter in wireshark again.

good idea.  yes, there should be a 'visible' flag, indeed.

> i doubt that wireshark supports colors, 

it supports coloring, but the normal use case is to allow the user to
specify coloring rules.  They are actually very useful, e.g. for
automatically displaying uplink messages with a different color compared
to downlink messages.  If you're not familiar with that feature yet, I
recommend to try it.

I don't yet know if a dissector plugin could overload the colors.  It
might be possible.  But even if it is, I think it should be a
preference of the gsmtap-log dissector, as e.g. yellow on white
background doens't look nearly as well as the yellow-on-black we use on
the terminal/console output...

> so i suggest to prefix the logging catergory in the summary (the list
> of packets shown in the upper part of wireshark's window) like this:
> ".... [DRLCMAC] gprs_rlcmac_data.cpp:100 [<tlli>] Poll timeout for DL
> TBF=0".

I was actually thinking of representing the category, filename and line
number as separate "fields" in wireshark.  This way, you can (or can
not) add them as separate columns to your list of packtes in wireshark.

I've hacked up most of the required libosmocore code, although the
separation of filename/line-number needs some modifications to the
current logging architecture (where the string-printing is done in the
core and the plugins only get the final result as opposed to the input).

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the osmocom-net-gprs mailing list