7 Oct
2009
7 Oct
'09
10:38 a.m.
Hey,
I think in the next days I will go around the sourcecode and change a couple
of logging messages. My two primary goals are increase the usefulness to figure
out what was going wrong and the second to be able to put some of these into
the syslog. Should we use DEBUG* to also log to syslog or introduce a new set
of macros?
Log Levels:
I think Harald has expressed the wish to introduce log levels. Should we
follow the log levels of syslog(3)?
Messages:
I would like to collect formats for various actions. Currently I'm thinking of
the following but would like to have more input.
subscriber:
When talking about a subscriber use TMSI, IMSI and Extension.
lchan:
Include refcount, channel type, link_id, subscriber
sccp:
Talk about SCCP source local reference and pointer
transaction:
Print the transaction?
gsm0408:
Print the lchan which prints the subscriber?
comments?
holger
7 Oct
7 Oct
4:56 p.m.
Hi Zecke,
On Wed, Oct 07, 2009 at 10:38:04AM +0200, Holger Freyther wrote:
I think in the next days I will go around the
sourcecode and change a couple
of logging messages. My two primary goals are increase the usefulness to figure
out what was going wrong and the second to be able to put some of these into
the syslog.
Thanks for addressing this. I always wanted to get around to do it, but didn't
find time so far.
Should we use DEBUG* to also log to syslog or
introduce a new set of macros?
I think it would be best to introduce a new logging macro, and turn DEBUGP into
a backwards compatibility macro that then calls/uses the new logging macro to
print a DEBUG level message
There is some code for log file handling in ulogd
(http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2), see ulogd_log() and
__ulog_log() in ulogd.h as well as __ulogd_log() in ulogd.c. It already
handles logging to a runtime choice of either syslog or a dedicated text file.
This is a feature that I'd like to see in openbsc, too.
In addition to that, we should support enabling of certain log levels and log
'groups' (like syslog facility, but more fine grained) to print to the telnet
interface.
So from the telnet interface, I want to be able to use vty commands to do
things like
* enable "WARNING" level messages on this telnet vty for all groups (MM, CC,
...)
* enable "DEBUG" level messages on this telnet vty for one specific group (SMS)
* change the log level and log groups for the logfile
Log Levels:
I think Harald has expressed the wish to introduce log levels. Should we
follow the log levels of syslog(3)?
yes.
I would like to collect formats for various actions.
Currently I'm thinking of
the following but would like to have more input.
all of those, plus
abis_nm needs formats for
* object class and object instance
* nm_state
since we probably need more and more of these, it might be interesting to think
of adding a new format character instead of %... % is already heavily used
especially in glibc.g
Regards,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5:18 p.m.
On Wednesday 07 October 2009 16:56:47 Harald Welte wrote:
Hi Zecke,
since we probably need more and more of these, it
might be interesting to
think of adding a new format character instead of %... % is already
heavily used especially in glibc.g
Do we mind GNUism? If not we could register special handlers for lchan,
subscriber and such.
holger
5:36 p.m.
On Wed, Oct 07, 2009 at 05:18:41PM +0200, Holger Freyther wrote:
I think we can make the assumption that we need gcc for compilation, but we
should not introduce arbitrary dependencies on things like the libc we're
using (which would make it impossible to build on BSD, windows, solaris or
macos, I guess).
Regards,
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
since we probably need more and more of these, it
might be interesting to
think of adding a new format character instead of %... % is already
heavily used especially in glibc.g
Do we mind GNUism? If not we could register special handlers for lchan,
subscriber and such.
9 Nov
9 Nov
4:20 a.m.
Hey LaForge,
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]...
The first thing is the introduction to have a log level. This will allow to set
a global log level or one by subsystem...
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...
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)
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.
At this point I would appreciate API feedback to see if it is useful to
continue this way or if another solution is better.
regards
z
[1] In the holger/new-debug-arch branch
10 Nov
10 Nov
8:17 a.m.
Hi 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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11 Nov
11 Nov
2:57 p.m.
On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte wrote:
I've now looked at it. I am not sure if we really need our own filter
language, whoch would just add a lot of ugly string parsing/handling code and
overall complexity. I mean, if you want to write that, do it :) But I think
there are other more important things to take care of...
Another topic is: How do you want to handle the log targets? I mean, there's
only one logfile or one syslog target, sure. But what about the VTY's? We can
have a number of VTY connections, and it may very well make sense to use one
non-debug VTY for issuing commands (without scrolling debug messages) and a
different VTY where you are mainly interested in seeing [scrolling] debug log.
So every VTY would register its own debug target after the telnet connection is
established?
Otherwise everything looks fine to me.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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.
3:05 p.m.
On Wednesday 11 November 2009 14:57:25 Harald Welte wrote:
On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald Welte
wrote:
I've now looked at it. I am not sure if we really need our own filter
language, whoch would just add a lot of ugly string parsing/handling code
and overall complexity. I mean, if you want to write that, do it :) But
I think there are other more important things to take care of...
I agree. I was thinking about the VTY case and we need to have a way to go
from string to code (enabling/configuring the filter) and I didn't want to add a
lot of VTY commands. Let me think about something easy here..
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.
Another topic is: How do you want to handle the log targets? I mean,
there's only one logfile or one syslog target, sure. But what about the
VTY's? We can have a number of VTY connections, and it may very well make
sense to use one non-debug VTY for issuing commands (without scrolling
debug messages) and a different VTY where you are mainly interested in
seeing [scrolling] debug log.
My idea was to add a "target" when the telnet connection is opened and remove
it when it is closed and by default not output anything.
So every VTY would register its own debug target after the telnet
connection is established?
Yeah.
Otherwise everything looks fine to me.
I hope to have a first implementation to toy with soon.
regards
holger
3:10 p.m.
Hi,
I think it would be nice to have Cisco-like approach with
term mon/term no mon commands in order to enable debug on one vty.
Regards
Roch.
Holger Freyther wrote:
On Wednesday 11 November 2009 14:57:25 Harald Welte
wrote:
On Tue, Nov 10, 2009 at 04:17:05PM +0900, Harald
Welte wrote:
I've now looked at it. I am not sure if we really need our own filter
language, whoch would just add a lot of ugly string parsing/handling code
and overall complexity. I mean, if you want to write that, do it :) But
I think there are other more important things to take care of...
I agree. I was thinking about the VTY case and we need to have a way to go
from string to code (enabling/configuring the filter) and I didn't want to add a
lot of VTY commands. Let me think about something easy here..
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.
Another topic is: How do you want to handle the
log targets? I mean,
there's only one logfile or one syslog target, sure. But what about the
VTY's? We can have a number of VTY connections, and it may very well make
sense to use one non-debug VTY for issuing commands (without scrolling
debug messages) and a different VTY where you are mainly interested in
seeing [scrolling] debug log.
My idea was to add a "target" when the telnet connection is opened and remove
it when it is closed and by default not output anything.
So every VTY would register its own debug target
after the telnet
connection is established?
Yeah.
Otherwise everything looks fine to me.
I hope to have a first implementation to toy with soon.
regards
holger
5286
days inactive
5321
days old
8 comments
3 participants
participants (3)
-
Harald Welte -
Holger Freyther -
Roch