This patch move this function to oml and we can use in
the future for doing a sanity check to all the received
OML message.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
This patch allows check the oml message correctly.
I have splitted the function in three different, one for
checking the manufacturer label ID, another for checking the
FOM and the principal which will call to the other function
for checking the OM header and all the part that I have told
before of the OML message received.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Classify the OML message and return the manufacturer type
or an error. Currently ETSI, ip.access and Osmocom are known.
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
I have split the function check_oml_msg, in two functions. One for
checking if the ipa header is well-formed and in check_oml_msg,
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
Make the sysmobts listen for OML messages on a Unix Domain Socket.
Messages passing a sanity check will be forwarded to the BSC.
In case the sysmobts-mgr detects a temperature above or below
temperature threshold an OML failure message will be sent
to the BTS.
[moved confinfo into the #ifdef BUILD_SBTS2050]
Signed-off-by: Alvaro Neira Ayuso <anayuso@sysmocom.de>
If the EEPROM tells us that a given unit doesn't support a given band,
we shouldn't try to use it, even if the BSC tells us to use an ARFCN in
such an unsupported band.
The reason is simple: The given BTS unit might have band specific
filter / duplexer / PA.
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3f. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.