22 Oct
2017
22 Oct
'17
7:03 p.m.
On 22 October 2017 at 19:20,
Snehasish Kar <snehasish.cse(a)live.com> wrote:
Hello Vadim
I tried using your trxcon along with grgsmtrx,
but when i start the app mobile in the l2l3 software
it gives me the following error:
Assert failed !check_element_exists(cnode, cmd->string) command.c:627
backtrace() returned 7 addresses
/usr/local/lib/libosmovty.so.3(install_element+0x136) [0x7f7a8c7fd4b6]
./mobile() [0x43d371]
./mobile() [0x40548e]
./mobile() [0x4049e7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7a8bffaf45]
./mobile() [0x404a83]
Please help.
Hi,
This message was forwarded to the ML. Please do the same
in the future to make others able to know about the problem
and possible solutions.
Actually, this crash isn't related to trxcon application
anyhow, it's caused by the recent libosmocore changes,
related to the VTY default nodes. A quick solution would
be to drop all custom 'exit' commands from the
'vty_interface.c'.
I'll try to fix the problem in spare time...
If you have some time and feel yourself able
to write a proper fix, just send me a patch,
and I'll review one ASAP ;)
BTW: we have some updates regarding to TX support.
Please look at the 'origin/ptrkrysik/trx' and
'axilirator/fixeria/trx' on GitHub.
With best regards,
Vadim Yanitskiy.
22 Oct
22 Oct
10:11 p.m.
On Sun, Oct 22, 2017 at 07:33:10PM +0330, Vadim Yanitskiy wrote:
Then it should be my fault. Can I do anything to help fix it?
Can you explain why custom 'exit' commands need to be dropped? That shouldn't
be the case for a telnet VTY, only while reading in VTY config from a file.
~N
I tried using
your trxcon along with grgsmtrx,
but when i start the app mobile in the l2l3 software
it gives me the following error:
Assert failed !check_element_exists(cnode, cmd->string) command.c:627
backtrace() returned 7 addresses
/usr/local/lib/libosmovty.so.3(install_element+0x136) [0x7f7a8c7fd4b6]
./mobile() [0x43d371]
./mobile() [0x40548e]
./mobile() [0x4049e7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7a8bffaf45]
./mobile() [0x404a83]
Please help.
Actually, this crash isn't related to trxcon application
anyhow, it's caused by the recent libosmocore changes,
related to the VTY default nodes. A quick solution would
be to drop all custom 'exit' commands from the
'vty_interface.c'.
23 Oct
23 Oct
12:12 a.m.
Hi Neels,
Can you explain why custom 'exit' commands
need to
be dropped? That shouldn't be the case for a telnet
VTY, only while reading in VTY config from a file.
I think, this happens due to the following change:
22bc45b8bfb8d0f2d8a46c6e945f3b4388fdced0
since which every application does install default
commands by default, including 'exit' and 'end'.
At the moment there are the custom 'exit' and 'end'
commands in the OsmocomBB/mobile/vty_interface.c.
So, the crash happens because it attempts to install
already existing commands.
Then it should be my fault. Can I do anything
to help fix it?
I've prepared a fix for that, have a look please:
https://gerrit.osmocom.org/4373
Also, I've fixed one more thing by the way:
https://gerrit.osmocom.org/4374
With best regards,
Vadim Yanitskiy.
4:54 a.m.
On Mon, Oct 23, 2017 at 12:42:25AM +0330, Vadim Yanitskiy wrote:
At the moment there are the custom 'exit' and
'end'
commands in the OsmocomBB/mobile/vty_interface.c.
So, the crash happens because it attempts to install
already existing commands.
Ah, damn. I checked all of the repositories I know to use the VTY, I didn't
imagine that OsmocomBB also has a VTY. That's really my fault then.
Lucky for me that the BB custom ones seem to merely dup the libosmocore stock
ones, so I get away with your patch:
Also, I've fixed one more thing by the way:
https://gerrit.osmocom.org/4374
well done.
Thanks for saving my A
~N
1:36 p.m.
Hi guys,
I have this in the gerrit/laforge/ournode-vty since October 14, and thre
was some discussion either on the ML or on redmine about it, otherwise
I wouldn't have written it at the time, while on holidays.
Regards,
Harald
On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
On Mon, Oct 23, 2017 at 12:42:25AM +0330, Vadim
Yanitskiy wrote:
--
- 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)
At the moment there are the custom 'exit'
and 'end'
commands in the OsmocomBB/mobile/vty_interface.c.
So, the crash happens because it attempts to install
already existing commands.
Ah, damn. I checked all of the repositories I know to use the VTY, I didn't
imagine that OsmocomBB also has a VTY. That's really my fault then.
Lucky for me that the BB custom ones seem to merely dup the libosmocore stock
ones, so I get away with your patch:
Also, I've fixed one more thing by the way:
https://gerrit.osmocom.org/4374
well done.
Thanks for saving my A
~N
1:43 p.m.
Hi Neels,
On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
Ah, damn. I checked all of the repositories I know to
use the VTY, I didn't
imagine that OsmocomBB also has a VTY. That's really my fault then.
I think in general we should not fall into that trap. We have *no clue* at all
who might be using libosmo* for whatever purpose. If we provide a libary with
a given API/ABI, then it's our responsibility to keep that ABI/API as stable as
possible.
I understand that it was hardly possible without fall-out in that particular
case, and for sure there are exceptions.
However, completely unrelated to this particular topic (and hence the Cc
to openbsc@) I'm not happy in general with the way how "carlessly" we
sometimes introduce breakage. We have to be more disciplined in general
on this. All of us.
BTW: The fact that this change has gone into master without being
noticed also means that possibly we're not modelling osmocom-bb as a
downstream user of libosmocore that needs to be rebuilt (and at least
checked if it starts up correctly?) whenever testing a libosmocore
change. That's also something to investigate. Maybe there's some way
we can test this without too much effort.
Regards,
Harald
--
- 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:24 p.m.
On Mon, Oct 23, 2017 at 12:43:52PM +0200, Harald Welte wrote:
I think in general we should not fall into that trap.
We have *no clue* at all
who might be using libosmo* for whatever purpose. If we provide a libary with
a given API/ABI, then it's our responsibility to keep that ABI/API as stable as
possible.
True.
There are ways to fix this one: we can allow to register a given command a
second time, which then replaces the previously registered command. We can also
allow this only for the common node commands.
Should I implement this? Then upon new release, all potential VTY users out
there can still register their own common node commands to replace the default
ones and should not experience breakage.
~N
2429
days inactive
2430
days old
baseband-devel@lists.osmocom.org
6 comments
3 participants
participants (3)
-
Harald Welte -
Neels Hofmeyr -
Vadim Yanitskiy