The old method used raw writes to the telnet FD, which is bad for
several reasons:
a) we don't know if we can actually write that many bytes to the
socket at the given time
b) the socket is still in blocking mode, so we could stall the entire
process
c) there may be weird interaction with the buffered writes of the
vty_out
Now, the print_welcome() functionality has moved to vty_hello() instead,
where we can use normal vty_out() in buffered mode.
This commit is expected to fix the garbled welcome message on arm-eglibc
targets.
It might still be a good idea to migrate the entire telnet interface to
libtelnet - but at some later time ;)
There is now a "libosmogsm.map" file containing an explicit list of
to-be-exported symbols. This should prevent us from leaking non-static
symbols into the global namespace.
A similar scheme should be adopted by all other osmocom libraries
No idea where I copied the original from but here we use the
other notation. (matches wikipedia and sources)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Rather than manually hard-coding numbers and using byte-arrays, we use
the msgb_*_{push,put}() function family of libosmocore/libosmogsm.
This is currently untested.
This code should not play with the internals of the msgb like this,
this code got introduced in af48bed556 and is breaking the
osmo-bts usecase of forwarding an RSL message.
Add a test case that fails without the new code. I would prefer if
we could get rid of the manipulating the msgb like this, it is prone
to errors like this one.
DATA REQ with a msgb_l3len(msg) == 0 message does not make any
sense, log an error and return immediately before attempting to
send an empty I frame in lapd_send_i.
If a sequence error is received, the N(R) variable must still be used to
acknowledge previously transmitted frames.
If there are two subsequent sequence errors received, ignore it. (Ignore
every second subsequent error.) This happens if our reply with the REJ is
too slow, so the remote gets a T200 timeout and sends another frame with
a sequence error. Test showed that replying with two subsequent REJ
messages could the remote L2 process to abort. Replying too slow shouldn't
happen, but may happen over serial link between BB and LAPD.
Written-by: Andreas.Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Note that this breaks the ABI and the low level API. But it shouldn't
break the high level API, nor the conv code definitions (because fields
default to 0, and for new fields '0' is the previous behavior)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This should have been done with 1dd7c84733
but somehow was missed and only applied to the 'finish' method and
not the 'scan' method.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
As it turns out, the previous fix didn't cover the case of a
timer X being re-scheduled inside a timer call back expiring at
the same time as the previous X instance.
Written-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Harald Welte
Sylvain Munaut
Holger Hans Peter Freyther