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/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgDear all,
when debugging Osmocom programs, one usually looks at either the pcap
trace of one of the many interfaces (Um interface via GSMTAP or
OsmocomBB, Abis, Gb, Gp or A interface via ethernet, ...) or at the log
files of the various osmocom programs.
Sometimes it can be hard to match the two different domains, and it is
useful to see in sequence when a certain message was received and what
kind of actions this triggered inside e.g. OsmoPCU or OSmoSGSN.
One could have used the libosmocore 'syslog' log target for this and
then configure the local syslog daemon to log to a remote syslog server
via the network. However, as there is another local process and context
switches involved, the messages were re-ordered. Also, syslog only
receives the fully-formatted log string, and not the meta-data like the
log level or sub-system.
Hence, the idae of having a GSMTAP based log target was floating around
the project for many years. I finally implemented this today.
The advantage is that in our single-threaded osmocom programs the GSMTAP
messages will leave in-sequence with the protocol messages received or
transmitted, and there is only the limited chance of re-ordering by the
local network stack and/or intermediate routers. Both shouldn't be much
of a concern during local debugging.
What do you need to use this?
1) The follwoing three libosmcoore commits from gerrit:
https://gerrit.osmocom.org/#/c/1355
https://gerrit.osmocom.org/#/c/1356
https://gerrit.osmocom.org/#/c/1357
2) a "log gsmtap" configuration in your config file (or via vty),
similar to how syslog logging is configured:
=== SNIP ===
log gsmtap localhost
logging filter all 1
logging color 1
logging print category 0
logging timestamp 0
logging level all everything
logging level rll notice
[...]
=== SNIP ===
3) a wireshark with my Change-ID I0de723445e5b5ce0199a4081808111240a9ed047
(can also be found in the laforge/gsmtap-log branch of
git://git.osmocom.org/wireshark or
http://git.osmocom.org/wireshark/commit/?h=laforge/gsmtap-log&id=3a207894a493598a3047fdfce88e72e3de21f774
I will leave this in review for a few days and then plan to merge it
into libosmocore. The wireshark patch will also be submitted at that
time.
A screenshot is attached for your reference.
There is of course no coloring of the lines in wirshark, but you can set
various wireshark filters (e.g. on log level, sub-system) and also use
colorization rules to e.g. map sub-systems again to colors.
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gsmtap-log.png
Type: image/png
Size: 107810 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20161202/96f979ac/attachment.png>