An according change in the OpoenBSC is following.
Since we're changing the external API we should probably increase a
lib version as well.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
Hi all;
I have deployed one ipaccess nanoBTS 1800, with OpenBSC (osmo-nitb) and all the osmocom suite apps.
I have already make succesfully GSM calls, SMS, and GPRS/EDGE packet data connections.
I now want support for sending binary SMS, i have read that with SMPP i would can.
I have compiled OpenBSC with SMPP but now I don´t know how to use it, i think it is in the OpenBSC vty, but i don´t know the commands or how to use the interface.
If you can give me some light in this thread i will grant you.
Sorry for my English
Best Regards
Jesús Vega Diaz
hi,
Daniel and me started a small report for the 30C3 network but we
are kind of stalled. Anyone feels like doing some review and
providing feedback?
holger
Hi list,
wouldn't be useful to have the possibility to choose (at least) between
UNIX and INET socket to be used for connecting to an external MNCC?
If this will be the case where should the choice be made? I was thinking to
add an extra option to bsc_hack but the choice can also be hard-coded
(prior to compilation).
cheers
luca
I wrote a blog post about running Osmocom on Parallella, with UmTRX:
http://www.rs-online.com/designspark/electronics/eng/blog/building-a-gsm-ba…
Just using the dual-core ARM in the Zynq, so nothing
surprising/interesting to this list and it's more of just an intro.
However, I'm curious as to opportunities for improving the performance
by offloading parts of the transceiver to the Epiphany chip. Does
anyone have any views on how practical this might be, effort involved
and potential gains etc?
Cheers,
Andrew
--
Andrew Back
http://carrierdetect.com
Currently ADM state change request that tries to set the
administrative state to the current value are immediately ACK'ed.
Beside the caching problem, this could lead the protocol
inconsistencies if two such requests are sent one after the other and
the second arrives before the procedure of the first has finished.
This patch removes the shortcut in oml_rx_chg_adm_state() which
immediately called oml_mo_statechg_ack(mo).
Ticket: OW#1132
Sponsored-by: On-Waves ehf
---
src/common/oml.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/common/oml.c b/src/common/oml.c
index 9ec773b..b7c12f7 100644
--- a/src/common/oml.c
+++ b/src/common/oml.c
@@ -765,11 +765,10 @@ static int oml_rx_chg_adm_state(struct gsm_bts *bts, struct msgb *msg)
return oml_fom_ack_nack(msg, NM_NACK_OBJINST_UNKN);
/* Step 2: Do some global dependency/consistency checking */
- if (mo->nm_state.administrative == adm_state) {
- DEBUGP(DOML, "... automatic ACK, ADM state already was %s\n",
- get_value_string(abis_nm_adm_state_names, adm_state));
- return oml_mo_statechg_ack(mo);
- }
+ if (mo->nm_state.administrative == adm_state)
+ LOGP(DOML, LOGL_NOTICE,
+ "ADM state already was %s\n",
+ get_value_string(abis_nm_adm_state_names, adm_state));
/* Step 3: Ask BTS driver to apply the state chg */
return bts_model_chg_adm_state(bts, mo, obj, adm_state);
--
1.7.9.5
Hi there,
I'm fairly new to the mobile world and am still coming to terms with a
whole new world of terminologies. The project is to test out a theory in
my lab before wanting to scale this at a larger level for commercial
purposes.
The intent is to be able to have roaming available with a roaming
aggregator in the United States with a small-scale mobile network enabled
using OpenSource software.
We are probably looking at implementing no more than 15 BTS's nationwide to
attract roaming customers at high traffic locations.
Our roaming aggregator would like us to send them MAP SS7 Messages from our
MSC.
My understanding of the requirements so far are:
1 x BTS (this could be a PC with some radio cards or something like a
nanoBTS)
1 x MSC/BSC/VLR
We won't be issuing any sim cards on our own network in the long run and
hence I don't see the point in us having a unique HLR.
Are there any gurus here that would be willing to share their intelligence?
--
Thanks,
Sahil
--
Thanks,
Sahil
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
Hello,
this patch series depends on two patches from Alexander (once they sign
handling is fixed):
sms: Fix gsm340_scts() to correctly decode absolute valid times.
sms: Fix support of negative timezone offsets in gsm340_gen_scts().
The first patch adds a test case to check that gsm340_scts is the inverse of
gsm340_gen_scts.
The next patches add a helper function to calculate the gmt offset and use
those in the *_scts functions.
The helper function is somewhat ugly, but it is the only portable way I could
find to get the GMT offset.
Ideas welcome
Regards,
Daniel
--
- Daniel Willmann <dwillmann(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
- Use time_t instead of abstract minutes to store validity time to make
sure we support all possible values.
- Return UNIX time from it to support both relative and absolute expire
times.
- Pass a current time to gsm340_validity_period() to compute the absolute
expire time if a relative time is specified. What time is "current" is to b
- We also introduce SMS_DEFAULT_VALIDITY_PERIOD macros to reduce number of
magic values.
PS This is a first patch of a series of patches which fix SMS validity time
decoding. I'm cleaning the patch set and want to see if this patch is fine,
as other patches rely on it.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
Indeed the problem has been already solved in the master branch by adding
the "expire_timer_stopped" attributes to a gsm_subscriber_connection and
then checking it upon expiration of the expire_lu timer for an active
subscriber.
Sorry to have re-raised the issue.
luca
Hi holger,
What is a network-initiated Location Area Update? Do you talk about
> the NITB/BSC advertizing periodic updating?
With Location Area Update I refer to the Location Update procedure (I made
confusion with the UMTS protocol where "Area" has been added in-between). I
also have to apologies about that "network-initiated" which is clearly
wrong since is the MS which triggers the procedure by sending a location
update request signal (what I meant is that the T3212 timer is provided to
the MS by the network).
> > I find this behavior annoying mostly in scenarios where the T3212 (LAU
> > timer) has been setup to a low value.
>
> About which software and which versions do you talk?
mmm, I didn't quite get your question here.
After performing further testing I can wrap up the issue as following: when
a MS ends a call after the expire_lu time, it will be considered expired in
the HLR (because two LUs were missed by the network). When the (now
expired) MS initiates a call, the CM service will be rejected by the
network with cause 4 (GSM48_REJECT_IMSI_UNKNOWN_IN_VLR). Needless to say
that when a different MS tries to establish a call towards the (now
expired) MS, this call will also be dropped because the destination MS is
(seen as) detached from the BTS.
Now I think that if we want to have a more precise location management, a
lower expiration interval is a possibilities: this can be achieved by
either lowering down the t3212 value and keeping the same expire_lu
calculation (2 times t3212 + 1 minute) or by modifying the expire_lu
calculation. In this scenarios the issue described above is more likely to
happen (higher probability of having ~10 minutes calls than > 60 minutes).
So indeed, is this behavior expected by the GSM protocol? I think that
update the HLR whenever an MS exits a call will be a costless procedure
which can avoid the annoyance of having the first next call dropped if this
happens prior to the triggering of the LU by the interested MS.
luca
The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: holger(a)freyther.de on Thu Mar 20 21:44:00 2014
Subject: DRAFT for a 30C3 report. Care to review?
Cause: Message body is too big: 1033152 bytes with a limit of 400 KB
Hi Holger,
On Sun, Mar 16, 2014 at 1:55 PM, Holger Hans Peter Freyther
<holger(a)freyther.de> wrote:
> E.g. in one
> of the testcases I noticed that you don't use C99 initializers but the
> old/error prone way of initializing. :)
Yes, I think in this particular case the old way is more compact and
thus more readable.
I added C99 initializers to the test (see the patch attached or
achemeris/sms-fixes branch) and to me it looks less readable and thus
more error prone. If you see any benefits of this patch - feel free to
merge it, though.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
Hi list,
when a MS is in a call it misses the network-initiated Location Area Update
procedure(s). This inconvenience can lead (if the call ends after the
expire_lu time) to having an attached (and active) subscriber marked as
expired in the HLR. Furthermore if at this point the MS initiates a new
call, the call will be dropped and (as expected) a new Location Area Update
procedure will be initiated by the BSC.
I find this behavior annoying mostly in scenarios where the T3212 (LAU
timer) has been setup to a low value.
To tackle this issue I thought of triggering a subscriber update when a
call get released (either by the network or by the MS) for each of the MS
involved in the call.
The code can also be optimized by checking whether the subscriber is
expired before performing the update.
I can provide a patch if you also consider the above as a misbehavior of
OpenBSC.
cheers
luca
The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
The OpenBSC(a)lists.osmocom.org mailing list has 2 request(s) waiting
for your consideration at:
https://lists.osmocom.org/mailman/admindb/openbsc
Please attend to this at your earliest convenience. This notice of
pending requests, if any, will be sent out daily.
Pending posts:
From: tlab.tester(a)googlemail.com on Mon Mar 3 13:01:09 2014
Subject: Unsubscribe
Cause: Message may contain administrivia
From: zielonka.markus(a)googlemail.com on Mon Mar 3 15:16:07 2014
Subject: unsubscribe
Cause: Message may contain administrivia
From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com>
The DSP/FPGA appears to report bogus PhDataInd with hlayer2 == 0.
Currently this would match the TRX==0,TS==0 and SS=0 and then we
report bad measurement reports. Add a magic number to the lower
eight bit of the hLayer2 to differentiate valid numbers.
Addresses:
<0004> measurement.c:97 (bts=0,trx=0,ts=0,ss=0) measurement during state: NONE
<0004> measurement.c:102 (bts=0,trx=0,ts=0,ss=0) no space for uplink measurement
---
src/osmo-bts-sysmo/oml.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c
index 596680f..7fcd4c6 100644
--- a/src/osmo-bts-sysmo/oml.c
+++ b/src/osmo-bts-sysmo/oml.c
@@ -704,17 +704,24 @@ err:
uint32_t l1if_lchan_to_hLayer(struct gsm_lchan *lchan)
{
- return (lchan->nr << 8) | (lchan->ts->nr << 16) | (lchan->ts->trx->nr << 24);
+ return 0xBB
+ | (lchan->nr << 8)
+ | (lchan->ts->nr << 16)
+ | (lchan->ts->trx->nr << 24);
}
/* obtain a ptr to the lapdm_channel for a given hLayer */
struct gsm_lchan *
l1if_hLayer_to_lchan(struct gsm_bts_trx *trx, uint32_t hLayer2)
{
+ uint8_t magic = hLayer2 & 0xff;
uint8_t ts_nr = (hLayer2 >> 16) & 0xff;
uint8_t lchan_nr = (hLayer2 >> 8)& 0xff;
struct gsm_bts_trx_ts *ts;
+ if (magic != 0xBB)
+ return NULL;
+
/* FIXME: if we actually run on the BTS, the 32bit field is large
* enough to simply put a pointer inside. */
if (ts_nr >= ARRAY_SIZE(trx->ts))
--
1.9.0
Got a problem with ipacces-telnet. My goal is to run osmo-nitb, and do some experimenting.
After a factory default reset, the following commands are given:
(192.168.1.11 is ip-address of the nanoBTS)
./ipaccess-config 192.168.1.11 -u 1808/0/0
./ipaccess-config 192.168.1.11 -o 192.168.1.1
./ipaccess-config 192.168.1.11 -r
(wait)
./ipaccess-config -n 0x400/0x400 192.168.1.11
Then I start ipaccess-telnet :
ipaccess-telnet 192.168.1.11 3210
And I start osmo-ntib:
osmo-nitb --config-file openbsc900.cfg
==========================================================
The biggest problem, that makes debugging difficult, is that I after having run osmo-nitb, I cannot use ipaccess-telnet anymore.
I have put in some additional prints into ip-access-auth.c to monitor the nanoBTS response:
Two examples of OK response, before osmo-nitb is run:
response: 3C 31 25 01 7C 3B B2 23 D6 7D 5D 84 17 62 9A 2E 9D 3E
= "<1% |;?#?}]? b?.?>" (length = 18)
response: 3C 76 B9 88 4C 43 D8 E3 1E 9A 2A 81 DD A0 C7 AC A5 3E
= "<v??LC?? ?*??O?>" (length = 18)
Two examples of response when nanoBTS refuse connection after having run osmo-nitb:
response: 7B 58 0D 7C A4 50 75 83 2B FB 38 F2 66 AD B0 B6 AA 7D
= {X?|?Pu?+?8?f????}" (length = 18)
response: 7B 43 4A E6 5B A7 E2 1D 1C 8D F4 88 FF FB 26 F6 69 7D
= "{CJ?[?? ?????&?i}" (length = 18)
Only a factory default reset will make ipaccess-telnet working again.
==========================================================
Output from osmo-nitb:
<0019> input/ipaccess.c:945 enabling ipaccess BSC mode
DB: Database initialized.
DB: Database prepared.
<001d> sms_queue.c:220 Attempting to send 20 SMS
<0019> input/ipa.c:308 accept()ed new link from 192.168.1.11 to port 3002
<0019> input/ipaccess.c:422 Sign link vanished, dead socket
<0019> input/ipaccess.c:260 Forcing socket shutdown with no signal link set
<0019> input/ipa.c:308 accept()ed new link from 192.168.1.11 to port 3002
<0019> input/ipa.c:308 accept()ed new link from 192.168.1.11 to port 3003
<0004> bsc_init.c:265 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 33 using MCC=1 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=40065:WARN:DHCP:dhcp_msg.c#692:Router Address not not valid: clearing it
Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=20233:WARN:DHCP:dhcp_msg.c#692:Router Address not not valid: clearing it
==========================================================
Output from ipaccess-telnet:
(NOT sure if this is exactly same run as shown in the osmo-nitb ouput)
nanoBTS (c) ip.access Ltd 2001
30351:DBG:CLI_SKT:Remote client 192.168.1.1 connected
3525:DBG:TIB:OCXO is now WARM
4032:DBG:IP_CHANNEL:Assigning RX Client A
4032:DBG:IP_CHAN_RX_A:4711:ipChanConn: EVENT 0x00001742 rxd in STATE notconnected
4032:DBG:IP_CHAN_RX_A:Attempting connection to 192.168.1.1:3002
4033:DBG:IP_CHAN_RX_A:4712:ipChanConn: EVENT 0x00001741 rxd in STATE outgoingconnecting
6198:DBG:IP_CHAN_RX_A:4789:ipChanConn: EVENT 0x00001744 rxd in STATE outgoingconnecting
19151:DBG:DHCP:Event 4 received in State 3
19151:DBG:DHCP:T1 expired, sending Request
19154:DBG:DHCP:Tr Timer started with period 112 secs
19155:DBG:DHCP:Event 2 received in State 4
19155:DBG:DHCP:ACK received
19155:WARN:DHCP:dhcp_msg.c#696:Router Address not not valid: clearing it
19161:DBG:DB_EE:Writing 232 bytes of DBX data to block 3
19161:DBG:DB_EE:Re-using existing DBX block
19200:DBG:DB_EE:NV block 3 - wrote block to NV, main and backup OK.
19200:DBG:DB_EE:EE update complete.
28158:DBG:IP_CHANNEL:Assigning RX Client A
28158:DBG:IP_CHAN_RX_A:5541:ipChanConn: EVENT 0x00001742 rxd in STATE notconnected
28158:DBG:IP_CHAN_RX_A:Attempting connection to 192.168.1.1:3002
28158:DBG:IP_CHAN_RX_A:5542:ipChanConn: EVENT 0x00001747 rxd in STATE outgoingconnecting
28593:DBG:OAM_IM:Changing SYSTEM LINK from 0.0 to 73.255
28650:DBG:DB_EE:EE update complete.
29719:DBG:OAM_IM:Stopping "Primary OML Fallback Client"
29719:DBG:OAM_IM:Stopping "Secondary OML Server"
29719:DBG:OAM_IM:Not stopping "Secure Secondary OML Server" - has not been started
29719:DBG:OAM_IM:Not stopping "IML Site Server" - has not been started
29719:DBG:OAM_IM:Not stopping "Secure IML Site Server" - has not been started
29719:DBG:OAM_IM:Stopping "IML Bts Server"
29719:DBG:OAM_IM:Not stopping "Secure IML Bts Server" - has not been started
29719:DBG:OAM_IM:Stopping "IRL Patched Routing Link"
29719:DBG:OAM_IM:Failed to inject event=1="STOP" into link source (token=7)
29744:DBG:IP_CHAN_SERVER:Closed server listening on port 3006
29745:DBG:IP_CHAN_SERVER:Closed server listening on port 3014
29935:DBG:IP_CHAN_RX_A:5705:ipChanConn: EVENT 0x00001743 rxd in STATE connected
29935:DBG:IP_CHAN_RX_A:5706:ipChanConn: EVENT 0x00001741 rxd in STATE disconnectclosing
==========================================================
Content of config file, openbsc900.cfg:
!
! OpenBSC configuration saved from vty
! !
password foo
!
log stderr
logging filter all 1
line vty
no login
!
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
short name OpenBSC
long name OpenBSC
auth policy closed
location updating reject cause 13
encryption a5 0
neci 1
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3103 0
timer t3105 0
timer t3107 0
timer t3109 4
timer t3111 0
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3141 0
bts 0
type nanobts
band DCS900
cell_identity 0
location_area_code 1
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id 1808 0
oml ip.access stream_id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn 33
nominal power 23
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config TCH/F
timeslot 6
phys_chan_config TCH/F
timeslot 7
phys_chan_config TCH/F
Odd Trandem
SINTEF ICT
This is a continuation of the patch series for the SMS validity fixes in
libosmocore.
Note, that this patch is based on top of the SMS DB change to remove
receiver ID. It is also available in the achemeris/sms-validity-fix-master
branch in the git repo.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
In a production system we should not store messages longer than
needed, as it will quickly bloat our DB. In case one wants to store
messages for debug purposes, we could add one of the following
capabilities later:
- hexdump to a log file
- send to an SMPP entry on delivery
- send to Wireshark
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co
gsm_7bit_decode() is deprecated. Replace it with gsm_7bit_decode_n().
The patch doesn't depend on anything and should be ready for merge
into the master.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc. / ООО УмРадио
https://fairwaves.co