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.orgHi 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)