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.orgHi zecke,
On Mon, Nov 09, 2009 at 04:20:09AM +0100, Holger Freyther wrote:
> in one way this is a continuation of the thread but there is no real need to
> quote anything. I went to ulogd and had a look (and copied the levels), I
> looked at what we have and what would be neat and came up with a small
> interface right now[1]...
ok, I will look at it asap.
> The first thing is the introduction to have a log level. This will
> allow to set a global log level or one by subsystem...
yes, that makes sense.
> The next thing is the concept of a target. We can add multiple targets
> (stdout, syslog, file, telnet) and have them be active at the same time (think
> of a loop inside the debugp statement). We can have a log level per
> target...
also makes sense, of course.
> The next thing is a "context". On the receive message path we start with
> the phsyical connection to the BTS, then with MM or RSL, going to GSM04.08,
> and then more protocols. On this path we can add a "context". E.g. we
> received this message for this bts, it was this lchan, it was this
> subscriber... (and the same for the sending path)
agree here, too.
> Having the context will allow to have filters. E.g. only show me RSL messages
> sent for the LCHAN assigned to SUBSCRIBER with the IMSI:XYZ. I foresee this
> useful when trying to debug things with the telnet interface in a real
> network.
yes, that makes even more sense. not sure to what level of complexity
we need to go. It's probably sufficient if we can already set the
context+loglevel, and then indicate a subscriber/imsi as filter. If
anybody wants something more sophisticated, like all messages on one
specific lchan/trx/bts/..., it's probably sufficient to simply ask him
to write the filter function in c code and somehow easily hook that into
the logging.
I mean, in any case we always have wireshark, too. But what wireshark
doesn't have at the moment is the context to trace all actions of one
subscriber, e.g.
So we should not try to over-engineer for every possible use case
--
- 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)