| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fi->T values are int, i.e. can be negative. Do not log them as unsigned, but
define a distinct timer class "Xnnnn" for negative T values: i.e. for T == -1,
print "Timeout of X1" instead of "Timeout of T4294967295".
The negative T timer number space is useful to distinguish freely invented
timers from proper 3GPP defined T numbers. So far I was using numbers like
T993210 or T9999 for invented T, but X1, X2 etc. is a better solution. This way
we can make sure to not accidentally define an invented timer number that
actually collides with a proper 3GPP specified timer number that the author was
not aware of at the time of writing.
Add OSMO_T_FMT and OSMO_T_FMT_ARGS() macros as standardized timer number print
format. Use that in fsm.c, tdef_vty.c, and adjust vty tests accordingly.
Mention the two timer classes in various API docs and VTY online-docs.
Change-Id: I3a59457623da9309fbbda235fe18fadd1636bff6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more
consistent. Upgrade to first class API:
- add timer grouping
- add generic vty support
- add mising API doc
- add C test
- add VTY transcript tests, also as examples for using the API
From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API.
The root reason for moving to libosmocore is that I want to use the
mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the
FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the
mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API
in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible
place for this.
osmo_tdef provides:
- a list of Tnnnn (GSM) timers with description, unit and default value.
- vty UI to allow users to configure non-default timeouts.
- API to tie T timers to osmo_fsm states and set them on state transitions.
- a few standard units (minute, second, millisecond) as well as a custom unit
(which relies on the timer's human readable description to indicate the
meaning of the value).
- conversion for standard units: for example, some GSM timers are defined in
minutes, while our FSM definitions need timeouts in seconds. Conversion is
for convenience only and can be easily avoided via the custom unit.
By keeping separate osmo_tdef arrays, several groups of timers can be kept
separately. The VTY tests in tests/tdef/ showcase different schemes:
- tests/vty/tdef_vty_test_config_root.c:
Keep several timer definitions in separately named groups: showcase the
osmo_tdef_vty_groups*() API. Each timer group exists exactly once.
- tests/vty/tdef_vty_test_config_subnode.c:
Keep a single list of timers without separate grouping.
Put this list on a specific subnode below the CONFIG_NODE.
There could be several separate subnodes with timers like this, i.e.
continuing from this example, sets timers could be separated by placing
timers in specific config subnodes instead of using the global group name.
- tests/vty/tdef_vty_test_dynamic.c:
Dynamically allocate timer definitions per each new created object.
Thus there can be an arbitrary number of independent timer definitions, one
per allocated object.
T_def was introduced during the recent osmo-bsc refactoring for inter-BSC
handover, and has proven useful:
- without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be
programmed with the right timeout value, for all code paths that invoke this
state change. It is a likely source of errors to get one of them wrong. By
defining a T timer exactly for an FSM state, the caller can merely invoke the
state change and trust on the original state definition to apply the correct
timeout.
- it is helpful to have a standardized config file UI to provide user
configurable timeouts, instead of inventing new VTY commands for each
separate application of T timer numbers.
Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5
|
| |
|
|
|
|
|
|
|
| |
Provide a va_list type vty_out() variant, to be able to pass on variable
arguments from other function signatures to vty_out().
This will be used by Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 for osmo_tdef.
Change-Id: Ie6e6f11a6b794f3cb686350c1ed678e4d5bbbb75
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove any special node exiting from the VTY CTRL-C handling.
From a curious VTY transcript test glitch, I noticed weird behavior by the VTY
telnet shell: usually, when the user hits CTRL-C, that means to cancel the
current command line and present a fresh, clean prompt. However, only on the
CONFIG_NODE and CFG_LOG_NODE, a CTRL-C also exits the current node and moves up
by one level. This behavior is unexplainable and makes zero sense.
No other nodes exit on CTRL-C:
- on the ENABLE node, a CTRL-C stays on the ENABLE_NODE and doesn't exit to the
VIEW_NODE.
- any sub-nodes of the CONFIG_NODE stay unchanged, e.g. 'network' or 'bts' /
'trx', etc.
There is no apparent special meaning of CTRL-C on CONFIG_NODE nor CFG_LOG_NODE
to justify this odd choice.
Particularly, the vty transcript tests using osmo_verify_transcript_vty.py rely
on sending CTRL-C to clear the command prompt, so that we can properly test
sending '?' to the VTY during transcripts. In a live session, a '?' prints
available options and then updates the prompt with identical command arguments.
In a transcript test, that doesn't make sense, because each time the transcript
writes out a new command to run. Consider e.g. a transcript test like:
tdef_vty_test(config)# timer ?
tea Tea time
test Test timers
software Typical software development cycle
tdef_vty_test(config)# timer tea ?
[TNNNN] T-number, optionally preceded by 't' or 'T'.
To be able to issue a fresh command after '?', osmo_verify_transcript_vty.py
explicitly sends a CTRL-C to clear the command buffer. Hence there we rely on
predictable behavior of CTRL-C.
More particularly, the upcoming osmo_tdef_vty transcript tests are apparently
the first that want to test '?' behavior on the CONFIG_NODE's root level and
fall on their face, because of the implicit exit that happens only there.
Change-Id: I4f339ba61f1c273fa7da85caf77ba116ae2697b1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cmd_complete_command_real(), detect and strip square braces from
multi-choice arguments, to enable tab-completion for commands like
> list
cmd [(alpha|beta)]
> cmd <TAB>
alpha beta
> cmd be<TAB>
> cmd beta
Change-Id: I8c304300b3633bb6e9b3457fcfa42121c8272ac0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since very recently we sensibly handle commands like
cmd ([one]|[two]|[three])
as optional multi-choice arguments. In addition, support the more obvious
syntax of
cmd [(one|two|three)]
Internally, the tokens are mangled to [one] [two] and [three], which is how the
rest of the code detects optional args, and makes sense in terms of UI:
> cmd ?
[one]
[two]
[three]
(i.e. optional arguments are always shown in braces in '?' listings)
Before this patch, commands defined with a syntax like [(one|two)], would lead
to an assertion (shows as "multiple") during program startup.
Change-Id: I952b3c00f97e2447f2308b0ec6f5f1714692b5b2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add basic optional multi-choice argument support.
The VTY detects optional arguments by square braces.
> cmd ?
[optional-arg]
> cmd optional-arg
ok
> cmd
ok
However, within multi-choice args, these braces were so far not treated as
optional:
> list
cmd2 ([one]|[two]|[three])
> cmd2
% Command incomplete
In preparation for I952b3c00f97e2447f2308b0ec6f5f1714692b5b2 which will enable
the more obvious syntax of
cmd [(one|two)]
for reasons of internal implementation, first support a syntax of
cmd ([one]|[two])
The internal vty implementation always needs square braces around each option.
There is currently no good way to prevent developers from defining braces
inside multi-arguments, so it is easiest to allow and handle them:
> list
cmd2 ([one]|[two]|[three])
> cmd2
ok
The VTY doesn't guard against a mix like
cmd (one|[two])
With this patch, a multi-choice command is treated as optional iff the first
element is in square brackets. The remaining elements' square brackets have no
effect besides confusing the user. This is not explicitly checked against.
In general, I would prefer to check all of these details, but the current VTY
code with its endless code duplication and obscure string mangling just doesn't
provide that luxury. There are numerous worse errors hidden in there.
Change-Id: I9a8474bd89ddc2155c58bfca7bd038d586aaa60a
|
| |
|
|
| |
Change-Id: I1bd973754b1ebc42283f6a07defa60f58523f5a3
|
| |
|
|
|
|
|
|
|
| |
In 99ae401e490e60fc07bef7eacc478be7bdcc9f5a we introduced the ability
to specify the TCP port to which the VTY should bind. However, the VTY
dcumentation wasn't extended accordingly, causing virtually all master
build jobs to fail.
Change-Id: I54fb0ca0d3a884a64a349b22de70f3d9bd1a6d54
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the vty_bind_cmd VTY command to allow to optionally specify
a port in addition to the IPv4 address.
Introduce telnet_init_default to relieve client code from having
to query the bind IPv4 address (and now the TCP port). Instead a
client only needs to pass the default TCP port to use.
Client code should use it like:
int rc = telnet_init_default(ctx, priv, OSMO_VTY_PORT_SGSN);
Change-Id: Id5fb2faaf4311bd7284ee870526a6f87b7e260f3
|
| |
|
|
| |
Change-Id: I38555c4d4f565ce21dda34fc3857c47b3d802dbd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Show each rate counter group's index in the output of the
'show rate-counters' command, to provide some way of telling
apart distinct instances of the same rate counter group.
This is not a very user-friendly UI because these indices are
generated internally by libosmocore and/or applications, so
users cannot easily assign meaning to these indices. However,
the current rate counter implementation doesn't allow for more.
Change-Id: Ieb151239407e4b2f8859fefec8d0670f5ddf908a
Related: OS#3674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When vty_out_rate_ctr_group_fmt() prints the description of a
counter group, it assumes this description should appear at
the beginning of a line. However, the caller might be printing
counters in an indented context. So just let the caller worry
about printing the group title if necessary (there is currently
only one known caller, which is updated in this commit).
Note that printing of the group title was an undocumented feature.
Change-Id: I2c55cb54e8b7a7c8c6cf72f22287083767ed0201
Related: OS#2660
|
| |
|
|
|
|
|
| |
Adjust wording so telnet command can be directly copy-pasted from the log to access
the interface without the need for further editing.
Change-Id: I1876447f9285adcd1b09937a6121afabd0b32e52
|
| |
|
|
| |
Change-Id: I07d105f4a810dd809fbf6feb5c04e7410020c887
|
| |
|
|
|
| |
Change-Id: Ibd81f29fa22d53553bd73c055d6a1f5255a69bad
Fixes: Coverity CID#135238
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We must explicitly check the return value of osmo_log_vty2tgt(), or may run
into a segfault. I wasn't aware of this and introduced numerous such cases in
I36f17c131cc70ce5a1aef62fd9693097de230cd4.
Reproduce: on the VTY, do not issue 'logging enable', invoke 'logging level
force-all LEVEL' first.
Show in logging_vty_test.vty that this situation is now again amended by
telling the user that logging was not enabled.
Related: OS#3611
Change-Id: Id11702d1801d6654ca5e5a51b597a0d802e2e8dd
|
| |
|
|
|
|
|
| |
We want to have well-formed config files that print exactly one space
per VTY/config node level, and not two.
Change-Id: Ia75c7067284ea225cffe13ca71bad05a7747ae66
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During 'show online help', the XML vty node dump, omit all commands marked
HIDDEN.
These commands were already hidden from the VTY reference prior to commit
I1f18e0e41da4772d092d71261b9e489dc1598923, because of broken/confusing bit and
boolean logic mixup. After that commit, HIDDEN commands end up in the doc. So
practically, this patch here brings back the status quo of before above commit,
even though the previous code clearly "intended" to list HIDDEN commands in the
reference but failed to have that effect.
AFAICT the complete list of commands currently hidden is:
* osmo-bsc: bts/"training_sequence_code <0-7>",
* osmo-bsc: ts/"phys_chan_config PCHAN" for uppercase pchans;
* osmo-bts: bts/"rtp bind-ip A.B.C.D" which actually says
vty_out(vty, "%% rtp bind-ip is now deprecated%s", VTY_NEWLINE);
* osmo-sgsn: 'reset sgsn state' used for SGSN testing.
Note that the osmo-sgsn build was broken by including hidden commands in the
vty reference, since one of its hidden commands had missing doc strings and
made osmotestconfig.py signal failure. This would fix that from the
hide-hidden-commands angle, and so would osmo-sgsn commit
I8b6e8615e409266910f2f76a10ced9ab33e4de91 from the fix-the-doc-strings angle.
Change-Id: I92c3c66ff69c186234276c64478d6342e061d25e
|
| |
|
|
|
|
|
|
|
|
| |
If a command is both hidden and deprecated, still don't show it for the 'list'
command.
We currently have no such nodes, as it seems, though.
Related: OS#3584
Change-Id: I07ec15cab057a3e09064e0420a69121ee8eb4253
|
| |
|
|
|
|
|
|
|
|
|
| |
In vty_dump_nodes(), make sure the bitwise & is evaluated first.
For the deprecation flag (0x1), the practical effect is most likely identical,
assuming that the boolean ! operator flips the first bit, so I expect no
visible functional difference. It still was confusing and wrong to look at.
Related: OS#3584
Change-Id: I1f18e0e41da4772d092d71261b9e489dc1598923
|
| |
|
|
|
|
|
|
|
| |
Add new command to once-off set each and every category to the given log level,
as discussed at length on the openbsc@ mailing list.
Show that it works in logging_vty_test.vty.
Change-Id: I4c3e4f786476cb813fdc0a7c64f30ee04758309d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add 'logging level force-all <level>' and 'no logging level force-all' as new
names for 'logging level all <level>' and 'logging level all everything'.
Resurrect the functionality of 'logging level all everything' -- even if it is
still deprecated because the name is confusing, it is now just an alias for
'no logging level force-all'.
Show in logging_vty_test.vty that we can now again lift the global logging
clamp, both with the new commands as well as with the deprecated ones.
Also show that 'force-all' is written back properly, if set.
Change-Id: I36f17c131cc70ce5a1aef62fd9693097de230cd4
|
| |
|
|
| |
Change-Id: If683b1272ad2d5b402b91c52c496aa7975bc6315
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'logging level all everything' has not had an effect for some time now. The
plan is to bring back its old functionality, but to keep it deprecated and
rather define a less confusing name.
* Deprecate 'everything'.
* Do not write 'everything' during 'write file' or 'show running-config', which
we curiously still do until now.
BTW, the reason why we need to compose a complete list of categories for the
deprecated 'everything' command is explained in detail in the commit log for
I3b083f27e3d751ccec258880ae7676e9af959a63
Change-Id: Ib75fedb0572570a61bb34ee729a2af86cf5f16da
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Completely drop the implementations of log_vty_command_{str,description}().
These functions have been public API once, marked as deprecated since
c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7 (March 2017). I considered to keep
them, or reduce them to useless stubs, but it is quite silly, really. These
functions are completely and utterly useless outside of libosmocore. Any
program linking these deserves to fail.
Re-implement vty logging level command gen, in logging_vty.c. logging.c is
simply the wrong place for that.
Introduce logging_internal.h to share logging definitions to logging_vty.c
without publishing as API.
Introduce static gen_logging_level_cmd_strs() to compose a list of category
arguments with their descriptions for VTY commands. Use osmo_talloc_asprintf()
instead of the previous error prone and chaotic strlen() counting method.
Do not dynamically generate log level arguments, just keep static strings. We
are super unlikely to ever change the log levels we have.
No changes in logging_vty_test.vty: proves that there is no functional change.
All of this, besides introducing basic sanity, is cosmetic preparation to be
able to re-use the generic command generation code for arbitrary commands with
category or level args (for deprecated and new keywords).
Rationale: I want to hide 'all' and 'everything' from the VTY command
documentation, by means of deprecating. I first tried to simply define a
deprecated 'logging level CAT everything' command:
logging level (all|rsl|rr|...) (debug|info|notice|error|fatal)
logging level CAT everything # <- deprecated and hidden
But unfortunately, command matching doesn't work as intended when the CAT
argument reflects a valid category; I want it to invoke the deprecated function
as soon as the 'everything' keyword follows, but it stays stuck to the "valid"
command when the category argument matches an explicit keyword in that list,
and will throw an error on the following 'everything' keyword. I.e.:
logging level rsl everything
% Unknown command # <-- leads to config file parse error
logging level unknown_string everything
% Ignoring deprecated 'everything' # <-- works only for invalid categories
So I need to define 'everything' separately, again with a list of each valid
category instead of a generic CAT arg.
Change-Id: I3b083f27e3d751ccec258880ae7676e9af959a63
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have osmo_str2lower() and osmo_str2upper(), but these lack:
* proper destination buffer bounds checking,
* ability to call directly as printf() argument.
Deprecate osmo_str2upper() and osmo_str2lower() because of missing bounds
checking.
Introduce osmo_str_tolower_buf(), osmo_str_toupper_buf() to provide
bounds-safe conversion, also able to safely convert a buffer in-place.
Introduce osmo_str_tolower(), osmo_str_toupper() that call the above _buf()
equivalents using a static buffer[128] and returning the resulting string
directly, convenient for direct printing. Possibly truncated but always safe.
Add unit tests to utils_test.c.
Replace all libosmocore uses of now deprecated osmo_str2lower().
Naming: the ctype.h API is called tolower() and toupper(), so just prepend
'osmo_str_' and don't separate 'to_lower'.
Change-Id: Ib0ee1206b9f31d7ba25c31f8008119ac55440797
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow printing the source file information *after* the log information.
Add target->print_filename_pos, log_set_print_filename_pos() and enum
log_filename_pos, and the optional 'last' keyword to the 'logging print file'
vty command. (An enum in case we want to add other positions later.)
Rationale: on log lines, the logging context is usually printed first in the
logging text. Without the source file information, this logging context pretty
much aligns in an easily readable way. When adding the source file information,
each line's logging context info is shifted right by a pretty much random
amount and it is hard to spot recurring logging contexts.
One solution is to switch off source file info, of course, but that's not an
option when actively hacking on bugs and new features.
For example, it is unnecessarily hard to spot lchan FSM related log lines in
this osmo-bsc log snippet:
DRSL NOTICE mgw_endpoint_fsm.c:603 mgw-endpoint(conn0){WAIT_MGW_RESPONSE}: Freeing instance
DRSL NOTICE fsm.c:381 mgw-endpoint(conn0){WAIT_MGW_RESPONSE}: Deallocated
DMSC NOTICE mgw_endpoint_fsm.c:603 SUBSCR_CONN(conn0){CLEARING}: Received Event FORGET_MGW_ENDPOINT
DCHAN DEBUG lchan_rtp_fsm.c:741 lchan(0-0-1-TCH_F-0){WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RTP_RELEASED
DCHAN DEBUG lchan_rtp_fsm.c:520 lchan_rtp(0-0-1-TCH_F-0){ROLLBACK}: Freeing instance
DCHAN DEBUG fsm.c:381 lchan_rtp(0-0-1-TCH_F-0){ROLLBACK}: Deallocated
DCHAN DEBUG lchan_rtp_fsm.c:520 lchan(0-0-1-TCH_F-0){WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RTP_RELEASED
DCHAN DEBUG lchan_fsm.c:1232 lchan(0-0-1-TCH_F-0){WAIT_RLL_RTP_ESTABLISH}: state_chg to WAIT_RF_RELEASE_ACK
DRSL NOTICE handover_fsm.c:762 handover(interBSCin_conn0){WAIT_RR_HO_DETECT}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRSL NOTICE handover_fsm.c:762 handover(interBSCin_conn0){WAIT_RR_HO_DETECT}: Freeing instance
DRSL NOTICE fsm.c:381 handover(interBSCin_conn0){WAIT_RR_HO_DETECT}: Deallocated
DCHAN DEBUG lchan_fsm.c:1196 lchan(0-0-1-TCH_F-0){WAIT_RF_RELEASE_ACK}: state_chg to BORKEN
DCHAN DEBUG lchan_fsm.c:354 lchan(0-0-1-TCH_F-0){BORKEN}: (type=TCH_F) Clearing lchan state
DLMGCP DEBUG mgcp_client.c:741 Tx MGCP msg to MGCP GW: 'DLCX 3 2@mgw MGCP 1.0'
DLMGCP DEBUG mgcp_client.c:743 Sending msg to MGCP GW size: 66
DRLL NOTICE mgcp_client_fsm.c:422 MGCP_CONN(to-BTS){ST_DLCX_RESP}: Received Event EV_DLCX_RESP
Placing the source file info behind the log text makes it much easier to
follow, while the source file info is still available:
DRSL NOTICE mgw-endpoint(conn0){WAIT_MGW_RESPONSE}: Freeing instance (mgw_endpoint_fsm.c:603)
DRSL NOTICE mgw-endpoint(conn0){WAIT_MGW_RESPONSE}: Deallocated (fsm.c:381)
DMSC NOTICE SUBSCR_CONN(conn0){CLEARING}: Received Event FORGET_MGW_ENDPOINT (mgw_endpoint_fsm.c:603)
DCHAN DEBUG lchan(0-0-1-TCH_F-0){WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RTP_RELEASED (lchan_rtp_fsm.c:741)
DCHAN DEBUG lchan_rtp(0-0-1-TCH_F-0){ROLLBACK}: Freeing instance (lchan_rtp_fsm.c:520)
DCHAN DEBUG lchan_rtp(0-0-1-TCH_F-0){ROLLBACK}: Deallocated (fsm.c:381)
DCHAN DEBUG lchan(0-0-1-TCH_F-0){WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RTP_RELEASED (lchan_rtp_fsm.c:520)
DCHAN DEBUG lchan(0-0-1-TCH_F-0){WAIT_RLL_RTP_ESTABLISH}: state_chg to WAIT_RF_RELEASE_ACK (lchan_fsm.c:1232)
DRSL NOTICE handover(interBSCin_conn0){WAIT_RR_HO_DETECT}: Terminating (cause = OSMO_FSM_TERM_REGULAR) (handover_fsm.c:745)
DRSL NOTICE handover(interBSCin_conn0){WAIT_RR_HO_DETECT}: Freeing instance (handover_fsm.c:745)
DRSL NOTICE handover(interBSCin_conn0){WAIT_RR_HO_DETECT}: Deallocated (fsm.c:381)
DCHAN DEBUG lchan(0-0-1-TCH_F-0){WAIT_RF_RELEASE_ACK}: state_chg to BORKEN (lchan_fsm.c:1196)
DCHAN DEBUG lchan(0-0-1-TCH_F-0){BORKEN}: (type=TCH_F) Clearing lchan state (lchan_fsm.c:354)
DLMGCP DEBUG Tx MGCP msg to MGCP GW: 'DLCX 3 12@mgw MGCP 1.0' (mgcp_client.c:741)
DLMGCP DEBUG Sending msg to MGCP GW size: 67 (mgcp_client.c:743)
DRLL NOTICE MGCP_CONN(to-BTS){ST_DLCX_RESP}: Received Event EV_DLCX_RESP (mgcp_client_fsm.c:422)
Implementation: for 'last', insert source file info only when an '\n' is found
at the end of the log line composition buffer, so that LOGP()...LOGPC()
constructs also print source file info only when a log line actually ends.
Change-Id: I393907b3c9e0cc1145e102328adad0a83ee13a9f
|
| |
|
|
|
|
|
| |
Setting age to 5 is cleary an error, it should be increment by one
instead as APIs were added 0.11->0.12 and none modified or removed.
Change-Id: I3b3bc808349bc2f949ef9eef64f39e7202ddf946
|
| |
|
|
|
|
|
|
|
|
|
| |
the vty_config_write function should write:
line vty
login
to the configuration file when the login is enabled. Otherwise after
saving the configuration the next login will be performed without
password checking (password_check variable will be 0 though it must be 1)
Change-Id: I39050b6bf617dac10d3fccc3106f67bdcca1d05a
|
| |
|
|
| |
Change-Id: I160728544c0effe45757df22f1ff2314fcb13dd1
|
| |
|
|
|
|
|
| |
Fixes crashes when using vty `show fsm-instances all`
when fsm children are present.
Change-Id: I4ae0bee7f7f57ec6675cfb52ca6cf0d523d15362
|
| |
|
|
| |
Change-Id: I7e66432f37e13fd4c31389e3d89593fa0981e58f
|
| |
|
|
|
|
|
|
|
| |
Since we ignore "logging level CAT everything" in logging_level_cmd, we
can never run into the case in which we have loglevel==EVERYTHING, so we
can simplify this code and make it esier for later removal of everything
keyword.
Change-Id: I4e76c65a11cc22616c6dfc632435617ebb861c03
|
| |
|
|
| |
Change-Id: Ie37be744abd8c47211d64877bcd17f94465bd423
|
| |
|
|
|
|
|
| |
valgrind complains about using unitialised bytes in syscalls.
I could imagine this happens when tcgetattr fails to set termios.
Change-Id: I9d165911fa3127afa8f836fa5c5c2e14a949474a
|
