As it turns out, the other range were affected too, so Anreas wrote
the fix for them as well.
Written-by: Andreas.Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
From the mail:
---
appended is another patch for fixing a bug in the calculation of the
frequency lists. This time the patch is for the "Range 256 format".
The problem is that the operand for the "smod" operation might be
negative, in this case the simplified version won't work as expected.
In the patch I introduced a separate function for "smod" which takes
care of the sign. I have not yet checked if the other formats are also
affected, this would be the case if the "smod" operand can be negative.
There might be other solutions to fix the problem without the need
for a separate function, however I have not thought further about it.
A test vector is the following frequency list ("Range 256 format",
first byte is the length):
09 8b 1c 83 8c 15 ef 02 2d 30
The correct ARFCNs are
569 571 576 578 586 608 712 715 719
The uncorrected version would instead return:
444 457 460 464 569 576 578 586 608
This means four ARFCNs are wrong which will cause problems if for
example the frequency list contains the ARFCNs for hopping.
----
Written-by: Dieter Spaar <spaar@mirider.augusta.de>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Additionally it wasn't possible to send concatenated sms from the vty.
To send multiple sms, it is necessary to use padding bits and add a user_data_header.
Therefore the gsm_7bit_encode function was splitted to gsm_7bit_encode and gsm_septets2octets.
gsm_septets2octets: this is the old gsm_7bit_encode function + additional padding parameter
Additionally the gsm_7bit_decode function was modified to take account for the user_data_header.
With the new gsm_get_octet_len function you can get the octet length for a given septet length.
I also added several sms tests.
* All loging prefixes in libraries should be DL like DLINP
* All signals / subsystems should be called S_L_* SS_L_*
* All command nodes should be called L_*_NODE
This makes sure existinc code still compiles as expected
This adds the libosmo-abis logging subsystems to libosmocore,
it uses the new change that harald proposed based on negative
numbers for library logging subsystems.
In snprinftf the size is a size_t (unsigned) in case we want
to write more than we have available, len_remain will be < 0.
This was spotted while removing hexdump from simtrace and comparing
it to our implementation.
int snprintf(char *str, size_t size, const char *format, ...);
In 8256076722 it was attempted to fix
a bug previously introduced by logging related changes. The problem
is that a va_list can be corrupted after it has been used once, so
we need to va_copy before each successive use.
And if we copy it, we also need to use the copy, and not the original ;)
We do this by using a trick: library-internal log categories use
negative subsystem numbers, which are converted into positive
array indexes at the time of logging.
library-internal log categories need to be knwo at compile-time,
while application-specified categories now are of unlimited number,
as they are dynamically allocated.
This extends the socket infrastructure in libosmocore to allow
to create non-blocking sockets.
Basically, it replaces the connect0_bind1 parameter by one
flags parameter.
and export the underlying raw value_string arrays instead:
abis_nm_obj_class_names / abis_nm_adm_state_names.
This permits the caller to use get_string_value() as well as
get_value_string().
osmo_sock_init_ofd() is a wrapper around osmo_sock_init() which will
take care of initializing and registering a 'struct osmo_fd' for the
newly-created socket.
* use write_queue where applicable
* provide functions that work on raw FD and those with osmo_fd
* add support for multiple gsmtap instances (no global variables)
Harald reported a problem in the logging:
http://lists.osmocom.org/pipermail/openbsc/2011-May/002896.html
Reverting 81e9636454 seems to
fix the problem. However, that workaround looks ugly.
Holger gives us another clue on what was wrong:
http://lists.osmocom.org/pipermail/openbsc/2011-May/002905.html
While digging in the manpage, I found this:
"The functions vprintf(), vfprintf(), vsprintf(), vsnprintf()
are equivalent to the functions printf(), fprintf(), sprintf(),
snprintf(), respectively, except that they are called with a
va_list instead of a variable number of arguments. These functions
do not call the va_end macro. Consequently, the value of ap is
undefined after the call. The application should call va_end(ap)
itself afterwards."
The plan is to collect structs and routines for application
setup and remove many copies of the boilerplate code we have
right now. This starts with routines to ignore certain signals
and the stderr init code.
Increment the age of the library because a new interface was added.
Summary of changes:
s/msg_entry/osmo_config_entry/g
s/msg_entries/osmo_config_list/g
s/msg_entry_parse/osmo_config_list_parse/g
minor glitch included in this patch while I was at it:
-#include "linuxlist.h"
+#include <osmocom/core/linuxlist.h>
This can be helpful where we send GSMTAP messages to the loopback
device (localhost, 127.0.0.1) from where the kernel would then
send ICMP reject packets as nobody is listening on that port.
This patch removes a workaround to fix some strange memory corruption
now that _output() has been completely reworked and we make use of
snprintf appropriately.
This patch reworks _output() to handle snprintf() return value
appropriately and to use one single buffer to build the logging
string, instead of four.
OpenBSC> logging level
all Global setting for all subsystems <----- this description was missing
rll A-bis Radio Link Layer (RLL)
[...]
This problem was introduced by myself in:
"vty: integration with logging framework"
04139f14b6
If the input value is '0' it should not really affect the error
since it's just an indecisive bit. We accept this either an internal
'0' (generated via puncture) or as an external '0' (generated via an
external puncturing scheme). A real received bit should never be '0',
it's always gonna be closer to 1 or the other value ...
(thanks to mad@auth.se on the ML for the idea)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Far from perfect but suits our need thus far.
The viterbi with softbit input is quite cpu-intensive. Since
most received bursts are often mostly error free, you could
use a less cpu intensive algorithm (Fano ?) and with hard bit
input. Then only switch to viterbi soft bit input if the channel
is bad enough to justify it.
Soft output is not implemented as its usefulness for the block
coding is limited.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
This patch moves all GSM-specific definitions to include/osmocom/gsm.
Moreover, the headers in include/osmocore/ have been moved to
include/osmocom/core.
This has been proposed by Harald Welte and Sylvain Munaunt.
Tested with `make distcheck'.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
libosmogsm which is provided by libosmocore.
I have also moved generate_backtrace() to backtrace.c instead
of gsm_utils.c, otherwise the timer and msgfile tests depend on
libosmogsm.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
The logging categories are registered by the applications, like
osmo-nitb, during startup. Thus, the VTY have to provide the logging
commands according to the logging categories that the application
has registered.
Before this patch, the VTY contained the logging categories
hardcoded. Thus, any change in the logging categories by the
application would not be shown by the VTY.
So far, this was not a problem because all applications used the
same logging categories. However, according to what Harald told
me, this may be a problem in the future.
This patch resolve the lack of integration between the logging
framework and the VTY by generating the VTY logging commands
from the logging categories registered.
Since this patch changes one function of the libosmocore API,
it follows another patch for the openbsc application to get in
sync with the new function layout.
I have reworked and renamed the functions:
* log_vty_category_string()
* log_vty_level_string()
to provide the new ones that generate the exact output that VTY
requires.
This patch does not release the memory allocated by
talloc_zero_size() to store the VTY strings for the commands
and the description. I found no exit function that can clean
up resources that were allocated.
It is possible that the queue is cleared after the select
and before the callback for writable is called. Check if
the list is not empty brefore taking an item out of it.
This makes more sense in case you run BCS, SGSN and other components
on the same host. Having multiple telnet sessions with the same
prompt can otherwise be confusing.
There should not be any u_int*_t types in this file, no need
to include this file. It is breaking compilation with the last
x86 build of GNU ARM for GCC 3.4.
This has two benefits:
- All people calling osmo_panic() will have the backtrace
- It makes the thing build in 'target' mode in osmocom-bb
And one downside:
- The osmo_panic handler is now in the backtrace
(I can live with that :)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
it returns if a given bit in the vector is "high" or "low".
the bitval that represents "high" depends on the bit position.
bitval2mask returns that. so we must check if the bit in the vector
equals the returned bitval.
It is easier from languages that dlopen libosmocore to have a function
to access this data than to poke at the bytes of the struct directly. Add
copyright for this method and the reset method I did earlier this year.
Use a while() {} to check offset +2 <= length on the first
iteration of the loop. Once we have the component length
check that it is going to fit into the given length.
The current USSD code is not doing any size checks, add a test
case to find out how easily we access the data out of bounds.
Begin to use the length in some places.
This file format will be used to store per country code,
per network code messages. This will be used for various
things ranging from access control, to messages...
These routines come from OpenBSC, the msgb_wrap_* functions
belong to Mike Haben, the rest is mine. The msgb allocation
is compatible to the GSM48 allocation in OpenBSC.
The highest bit must be set as "No extension byte" marker,
so that the next byte is considered to be the BCD number
and not some more control stuff
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The nat code stumbled over the CIC bug as it was detecting
timeslot 0x1 as a new CIC and we were patching the data outside
the actual packet... The TLV parser needs some better size
checking too.
It is easier to call these two functions from bindings than
wrapping the vty structure and figuring out the alignment of
the enum on all different ABIs.
The method should be renamed to is child of config node
as it was comparing if vty->node > CONFIG_NODE. This is
fixing an assert in go_to_parent as we tried to find a
parent for the CONFIG_NODE.
bsc_register_fd on an already registered fd can corrupt the list
in a heavy way and make the select end in an infinite loop, this
code will workaround the issue and provide a way to set a breakpoint
at the right position in the code.
This also includes an option for a minimal 'infinite loop' type
panic that could be required for embedded target that don't have
abort() or fprintf()
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
make sure to return the number of actually written bytes gsm_7bit_decode:
calculate length of resulting septets from input length before decoding
The input length to gsm_7bit_decode reflects the number of encoded bytes
to be decoded. As the decoding is done on the input in septetes we need
to take this into account and recalculate the length.
If a second ends, we add the number of events in that just-ended second
to the number of events in the currently running minute. The same happens
at the end of a minute: We add the number of events in that just-ended
minute into the number of events of the still-running hour, etc.
This gives a much more meaningful numbers and we don't end up with
"12 events per second, but 0 events per minute" kind of situations
anymore.
A 'rate counter' is a counter that counts events but also keeps
track of the rate of events (per second, minute, hour and day).
'rate counters' are generally abstracted in 'rate counter groups',
which are instances of a 'rate counter group description'. This
way we can have e.g. a description describing what kind of counters
a BTS (or TRX) has - and we can then create one instance of that
group for every BTS or TRX that exists.
This breaks the ARM build in osmocom-bb. Besides uint??_t seems to
be the preferred type in osmocore. (coming from stdint.h vs sys/types.h)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Right now I'm seeing crashes when removing a link and deleting
it and I need this hack to make it not crash. We will have to
understand if llist_for_each_entry_safe has a bug or if we are
doing something bad with the list (anchors not properly initialized).
Before this patch, there was a bug in the code caused by a memcpy
from one data structure to another. unfortuantely the data structures
were not the same, so we have to explicitly iterate over the array
and assign the structure members manually.
As the debug subsystem number is used as index into the debug_info_cat
array, there is no need to store the number explicitly inside the
structure again.
* I'm doing a nonblocking connect and for this I need to select
on writable and the first thing I need to do is to check the
SOL_SOCKET SO_ERROR state. I realize this by setting a different
cb on the embedded bfd during setup and then go back to the real
implementation.