Dear Osmocom community,
starting from 16th of January (until 7th of February) we can apply
Google Summer of Code as an Open source mentor organization. Many
well-known projects, such as Debian, FFmpeg, Apache, Git, GCC,
GNURadio and others, have been participating last year.
Personally, I think it's a great opportunity to move some of our
projects forward. I would like to know your opinions about this
idea, should we participate? I would be happy to be a mentor.
With best regards,
Vadim Yanitskiy.
The new product from Lime is marked to start shipping tomorrow. As far
as I understand it is basically the LimeSDR mini with a GPS disciplined
clock and a Raspberry Pi module, so it /should/ run osmo-bts +
osmo-trx-lms fine, and without clocking issues.
It also has POE.
I was wondering if anybody else has looked at it, has comments, or has
or is thinking of ordering one?
Thanks!
As a bit of relaxation in-between the serious hacking, I gave a little idea of
mine a spin, which could improve our use of static string buffers.
My idea is to use one common static buffer string, as a ring buffer, for all
our osmo_xxx_name() functions, that returns new chunks of static string every
time. Why?
The point is that we have many osmo_xxx_name() functions that return a string
in one single static buffer. When you call it a second time, it overwrites the
buffer. So this doesn't work:
printf("PLMN changed from %s to %s\n",
osmo_plmn_name(old_plmn),
osmo_plmn_name(new_plmn));
No matter what, this will always print the same string twice, and probably
no-one would notice.
For this, I have previously often invented xxx_name2() functions:
printf("PLMN changed from %s to %s\n",
osmo_plmn_name(old_plmn),
osmo_plmn_name2(new_plmn));
With osmo_plmn_name2() being:
"Same as osmo_plmn_name(), but returning in a different static buffer."
That is bad for these reasons:
- each new separate function adds another static buffer to the program size,
which remains unused all the other time.
- each new separate function adds more API signatures.
Alternatively we have xxx_buf() functions, but they are more cumbersome to use:
char buf[123];
gsm0808_cell_id_list_name_buf(buf, sizeof(buf), cil);
LOGP(DMSC, LOGL_DEBUG, "%s\n", buf);
Particularly for logging, that would always run even though the logging
category might be switched off.
So I came up with these patches, and changing all of current libosmocore's
static buffers to using this does work:
http://git.osmocom.org/libosmocore/log/?h=neels/static_strings
(second last patch introduces the API, last patch changes all libosmocore callers)
Also pushed to gerrit for easier review:
https://gerrit.osmocom.org/13061
the benefits:
- All osmo_xxx_name() functions can be called N times in a single printf()
statement, without the need for managing buffers.
- No osmo_xxx_name2() functions for "separate static buffer"
- Just fire off LOGP() args and the code gets skipped if the category / log
level is switched off:
LOGP(DMSC, LOGL_DEBUG,
"PLMN changed from %s to %s, but Fred says it was %s\n",
osmo_plmn_name(old_plmn),
osmo_plmn_name(new_plmn),
osmo_plmn_name(freds_plmn));
I think it would be nice to have this mechanism for easier string hacking,
but not sure if the tradeoffs / vague side effects are worth it.
So this might as well remain a fun idea that never made it.
Thoughts welcome.
Implementation considerations...
At first I thought a plain ring buffer returning the next bit of memory every
time would suffice, but I didn't like the need to vaguely trust that we never
use overlapping memory.
The best I could come up with was to guarantee up to N subsequent static
strings as non-overlapping. See the semantics around the 'recent' members.
But that entails an uncomfortable tradeoff:
I kind of expected to reduce the size of static char buffers in libosmocore,
but if I want to disallow overlapping N uses, the buffer has to be able to hold
N subsequent allocations of the largest buffer, which currently is 4100. So I
end up with a larger static char buffer. The advantage however is that every
libosmocore using program with its own xxx_name() functions can now use the
same static string space and does not need to add more static buffers all over
the place.
To make the buffer smaller, I considered taking the largest buffer callers out
of this, i.e. osmo_hexdump() and msgb_hexdump(). But particularly
osmo_hexdump() is one of the functions that I would like to be able to call
more than once in a printf() arg list. Actually that would in practice be of
smaller size than the maximum 4096 currently allowed. But the 'recent' check
above requires the *largest* size to fully fit N times.
Consider: if I choose a total buffer of 4096 bytes and print one hexdump of
3084 bytes, then I can't print another such buffer: the osmo_static_string()
function can't know that the first printf() has already concluded, and still
considers that large chunk as in-use. So to be able to allow any number of
subsequent printf()s of the same huge size, I need the number-of-recent-checks
times that large size to fit in the static buffer.
So there is a tradeoff between how many previous buffers I can guarantee to be
unchanged vs. the maximum buffer size allowed per allocation.
I would actually like to ensure 10 or more recent buffers, so that a caller can
say: I can use up to 10 various osmo_xxx_name() functions in the same printf()
statement, and libosmocore will barf if I use too much.
I would also like to use less static char buffer -- but is ten times 4096 as
static string buffer really a lot? Not for an x86_64 desktop machine, but what
about embedded targets?
Since in practice the name buffer sizes we use are more like <80 chars each, in
practice we would be totally fine with one 4096 char buffer.
I have never seen a hexdump of 4Kb in practice.
I'm considering actually removing the 'recent' check again and just offloading
the responsibilty for name buffer usage to the caller.
Or I'm considering to reduce the max hexdump / msgb_hexdump size to something
saner like 1024 chars or even 256 chars. (Actually, hexdump could also loop in
chunks of 64 bytes or something like that).
Another consideration was about how to effect bounds checking. I don't want to
evaluate return values in printf() args. So I decided to provide generalized
API that returns NULL pointers if the size did not fit, but for convenience use
have one osmo_static_string() function that OSMO_ASSERT()s as soon as the size
doesn't fit, instead.
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Dear Osmocom community,
for the last 10 days our "Debian installation test" job is consistently failing,
see https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/
It somehow seems to be related to soapySDR mismatching versions where we use a 0.5 package
from the debian feed:
> Get:358 http://deb.debian.org/debian stretch/main amd64 libsoapysdr0.5-2 amd64 0.5.4-1 [64.4 kB]
and mix that with a 0.7 lms7 module from our feed:
> Get:425 http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9… ./ soapysdr0.7-module-lms7 19.01.0-1 [49.9 kB]
> Unpacking soapysdr0.7-module-lms7:amd64 (19.01.0-1) ...
> dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack):
> trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package
...
> Errors were encountered while processing: /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Build step 'Execute shell' marked build as failure
> Finished: FAILURE
Does anyone know of any change that would have triggered this?
I've created https://osmocom.org/issues/3809 to track this.
Regards,
Harald
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi,
Currently if you call osmo_fsm_dispatch from a function that happens
to have been triggered by another call to dispatch, things can get a
little bit messy (depending on where that callback is in the chain of
even that may/may not change the state of the FSM).
So what I would propose is that any event dispatched to an FSM will be
processed only after the processing of any previous event is fully
completed (in the order they were generated). I have a prototype
implementation for review on gerrit :
https://gerrit.osmocom.org/c/libosmocore/+/12983
Now, this does break some tests, but looking at the breakage, it looks
just like message re-ordering at first glance. I guess running the
whole full range of test on this would be useful.
There are also another consequence is that it's now impossible to
return an error code if that event can't be handled in the current
state (previously dispatch would return -1). But since the actual
dispatch can be deferred ... well, can't do much. Looking at the
codebase, that error code is ignored most of the time. When it's
returned, it seems to always end up being ignored at the end of the
chain (because well ... realistically there isn't much you can do
about it anyway, it's a programming bug if it happens).
Thoughts / Comments ? Useful ? Crazy idea ? ...
Cheers,
Sylvain
Hi everyone,
let me remind you that I am refactoring the RAN connection in osmo-msc to allow
for inter-MSC handover. Patches merged to osmo-msc now are almost guaranteed to
produce merge conflicts. Cosmetic changes to RAN code are likely to be obsolete.
I would prefer if you guys wouldn't bother for another few weeks.
Thanks,
~N
See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/395/display/redire…>
------------------------------------------
Started by timer
Building remotely on build2-deb9build-ansible (ttcn3 osmo-gsm-tester-build osmocom-gerrit-debian9 osmocom-master-debian9 coverity) in workspace <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/>
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git://git.osmocom.org/osmo-ci
> git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/> # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/>
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:772)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to build2-deb9build-ansible
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:955)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor338.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy87.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1146)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1810)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/"> returned status code 1:
stdout:
stderr: <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/.git>: No space left on device
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770)
... 11 more
ERROR: Error cloning remote repo 'origin'
Dear Osmocom community,
It has recently been uncovered that there are some problems in the OML bringup
sequence between OsmoBSC and OsmoBTS.
Basically, the core of the issue circulates around the RADIO CARRIER managed object.
* OsmoBTS is accepting OPSTART even though no attributes (such as ARFCN) are set
* OsmoBSC is sending OPSTART twice for this MO, while it's only sending it once
for all other MOs
The problem now is: If we "fix" the BTS side to reject the OPSTART without
prior SET RADIO CARRIER ATTRIBUTES, then older OsmoBSC will stop to work with
newer OsmoBTS.
The underlying issue is that if we OPSTART the transceiver before setting the ARFCN,
then the later setting of attributes is no longer going to do anything, as the radio
has already started with "ARFCN 0".
TS 12.21 is not very clear on *when* attributes are permitted to be set.
The MO can be either locked or unlocked, or it can be enabled or not...
My idea so far was that if you want to change attributes of a MO (such
as the ARFCN), you need to first bring it down somehow (e.g. set it to
"locked"), then make the change and finally bring it online again.
A bit of playing with a nanoBTS revealed that it actually permits the
OPSTART not only before the attributes are set, but also before the
software has even been activated for that MO. This makes no sense
whatsoever, though.
More details in: https://osmocom.org/issues/3789 and https://osmocom.org/issues/3782,
particularly the last few updates to those tickets.
Any ideas?
--
- 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)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160
(1619189->1619249)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 82592960 vs
160 (1619505->1619436)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160
(1619471->1619531)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 82591360 vs
160 (1619587->1619475)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2080 vs 160
(1619557->1619613)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 82594400 vs
160 (1620892->1620862)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 1440 vs 160
(1620862->1620900)
Very large value, is this a typecast / intsize problem ??
Gullik
The values reported by the "show connections" command seem suspect to
me. I frequently have a uplink
value of around -60 dBm, but RXQ values showing 1-4 or so. While I move
about a lot, I anticipate fading,
but there seems to be a too big BER when compared with the "healthy"
signal level.
When testing ul / dl on the Mini, I found values that reasonably well
corresponded between spectrum
analyzer and "show connections".
The downlink is, I assume, reported by the MS. The question comes up how
to verify the relatively "new"
LimeSDR Mini / and the osmo-trx-lms with regards to this issue.
I have made some improvements to the TX, and now have a nice +10 - +17
dBm signal which is indicated
by the phones. I have more than 100 m range with regards to the phones (
crappy ? ) bargraph indicator,
at least 2 bars in the periphery, and always 5 bars inside the house /
lab. Antennas are inside, and the house
made of timber. However, reception seems to be the limiting factor right
now.
Q: I have deduced that RXQ is referenced in abis_rsl.c in the bsc, is it
just propagated from the sdr up
through Transceiver, where is the actual evaluation done?
Other thoughts on this....
Regards,
Gullik
Hi,
I cannot find a description of this command in the manual. This is very
useful to debug
ms, antennas and radio.
OsmoBSC> show conn
Active subscriber connections:
conn ID=232, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw
BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
Connection: 1, State: ESTABLISHED
BS Power: 0 dBm, MS Power: 10 dBm
Channel Mode / Codec: SPEECH_V1
No Subscriber
Bound IP: 192.168.1.75 Port 16404 RTP_TYPE2=0 CONN_ID=0
Conn. IP: 192.168.1.70 Port 4084 RTP_TYPE=3 SPEECH_MODE=0x00
Measurement Report:
Flags:
MS Timing Offset: 0
L1 MS Power: 10 dBm, Timing Advance: 4
RXL-FULL-dl: -73 dBm, RXL-SUB-dl: -73 dBm RXQ-FULL-dl: 0,
RXQ-SUB-dl: 0
RXL-FULL-ul: -57 dBm, RXL-SUB-ul: -58 dBm RXQ-FULL-ul: 0,
RXQ-SUB-ul: 0
I guess "dl" means downlink, from BTS to MS, and "ul" means uplink, MS
to BTS.
But, what is the difference between FULL and SUB ? What does the two
rightmost items mean,
those which are 0 in the above? What does the "No Subscriber" mean,
should that be IMSI ?
Still on the subject of LimeSDR Mini, now debugging radio and antenna
arrangements.
Regards,
Gullik
Recently, fixeria brought up that it would be better to not align wrapped lines
with an opening brace, but rather have a constant indent for wrapped lines.
I'd like to ask for the general opinion / kernel style compliance.
What indenting is acceptable?
For a long time my opinion was that opening brace alignment is better for
readability, but my opinion has shifted. I now find it more desirable to keep a
constant indent.
Consider:
unsigned int my_function_signature(int a_very_long_parameter,
int wrapped_line,
int another_line);
If a patch modifies the return value or the name, the patch either touches
three lines or leaves inconsistent indenting behind:
int my_func(int a_very_long_parameter,
int wrapped_line,
int another_line);
Also, a very long function name wastes a lot of usable linewidth for indent for
all arguments.
I've submitted a lot of patches over the years that touch more lines than
necessary, and left quite a few inconsistent indents behind, because an
automatic find-replace doesn't fix subsequent indenting.
I'm currently editing a lot of the osmo-msc sources and changing my mind about
API, so this line indenting due to renames issue comes up. I thought I could
pick a constant indent now while I'm at it.
If we had a single tab as indent, the function signatures' indenting would be
independent from the length of the name, and a find-replace leaves behind
consistent indenting / no whitespace changes needed for renames:
unsigned int my_function_signature(int a_very_long_parameter,
int wrapped_line,
int another_line);
int my_func(int a_very_long_parameter,
int wrapped_line,
int another_line);
I finally understood the vim cindent options to achieve this:
:se cino=(1s,u1s
(Forgive me if this is a bit too vim specific for your taste; I definitely want
vim to automatically give me the desired indenting.)
My problem with that is that it also affects if- and for- statements: 'if' and
'for' will never change their name, so aligning with opening-brace is unlikely
to ever cause unnecessary whitespace change. What was:
// vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(0,u0,/0,:0
int my_func(int a_very_long_parameter,
int wrapped_line,
int another_line)
{
if (a_very_long_parameter == 3 || a_very_long_parameter < 0
|| wrapped_line == 7
|| (one_level_deeper
&& (one_level_deeper
|| foo)))
return 5;
}
Now becomes:
// vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(1s,u1s,/0,:0
int my_func(int a_very_long_parameter,
int wrapped_line,
int another_line)
{
if (a_very_long_parameter == 3 || a_very_long_parameter < 0
|| wrapped_line == 7
|| (one_level_deeper
&& (one_level_deeper
|| foo)))
return 5;
}
(The cino=k0 parameter does control 'if', 'for' and 'while' separately, but
there is no way to tell it to brace-align while the '(' option is set to
'(1s', stupid quirk in cinoptions.)
IMHO aligning with opening brace improves readability of the nested conditions
and uses more of the line width. But I could get used to that, I guess. I think
I've seen this used a lot in Osmocom, too.
Another thing to consider:
if (a_very_long_parameter == 3 || a_very_long_parameter < 0
|| wrapped_line == 7)
return has_same_indent_as_condition(" :/ ");
I could use two tabs for in-brace indenting, but I haven't seen that anywhere
before, and it makes wrapped conditions waste a lot of line width:
// vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(2s,u1s,/0,:0
int my_function_signature(int a_very_long_parameter,
int wrapped_line,
int another_line)
{
if (a_very_long_parameter == 3 || a_very_long_parameter < 0
|| wrapped_line == 7
|| (one_level_deeper
&& (one_level_deeper
|| foo)))
return 5;
if (a_very_long_parameter == 3 || a_very_long_parameter < 0
|| wrapped_line == 7)
return 5;
}
I think I'll adopt fixed single-tab indenting in my patches from now on:
:se cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(1s,u1s,k0,/0,:0
Any (strong) opinions on / best practices for this?
Which one is more consistent with linux kernel style?
Thanks!
~N
Dear Osmocom community,
Does somebody have experience using multiple 3G femtocells connected to a single
HNBGW? Do cell reselection and handover work properly? How did you configure it?
Also, Osmocom (or Syscmocom?) used 3G networks at Congress 35c3. Were you using
multiple femtocells?
Were they connected to the same HNBGW? How did you configure them for cell
reselection and handover to work smoothly?
Thank you!
Kind regards, Mykola
Hi Oliver,
I've already spent some time on a first draft for the new messages we will need
to implement the E-interface via GSUP for inter-MSC handover. It would be
excellent if you could take over from what I have so far.
I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho:
http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/…
Anyone else is also more than welcome to take a look and remark on anything
that might seem a bad idea, etc.
This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC
handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to
freely share the trace, let me know if you need details.
The most interesting bits in the draft are
- the new message types
- the newly added IEs (see "Of which are newly added...")
The tasks for you would be:
- Spell out the protocol messages in common/chapters/gsup.adoc
- Implement the definitions in gsup.h
- Implement encoding and decoding, and tests
It is not so trivial to understand what goes with which message; maybe you
don't even need to know in detail? But if any info is still missing for you to
grok what's going on, don't hesitate to ask, as always.
Also interesting to figure out: Implement the IPA routing for which I added the
source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr
forward messages to each other via GSUP.
- Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and
to extend the gsup_server so that we can use the source_name/destination_name
IEs to forward GSUP messages between the two clients. (I added these because
I'm fairly certain there is no existing in-band IPA protocol bits that would
allow such routing; but I only briefly skimmed it, wouldn't hurt if you could
verify that again.) The aim is to have plain gsup_client API to allow me to
"just send messages back and fort".
- The session_id/session_state: we still need to figure out how to avoid
collisions in session_id numbers, as any peer may at any point re-use the
same session_id. Vadim suggested using a TI flag that gets flipped between
sender and receiver, but since there are more than two peers, I guess we
should treat each session_id as subordinate to a Request's source_name. IOW,
any peer owns the entire session_id number space itself for sending out
Request message types, and a Response or Error message type echos this
session_id back with the source_name then having become the destination_name;
it is perfectly legal for two peers to use the same session_id and collisions
are avoided by Request vs. Response/Error. Something like...
MSC-A MSC-B MSC-B'
-------> FOO_REQUEST(source=alice, destination=bob, id=3, state=BEGIN)
<------- FOO_RESPONSE(source=bob, destination=alice, id=3, state=CONTINUE)
-------> BAR_REQUEST(source=alice, destination=bob, id=3, state=CONTINUE)
<------- BAR_RESPONSE(source=alice, destination=bob, id=3, state=CONTINUE)
---------------> FOO_REQUEST(source=alice, destination=fred, id=4, state=BEGIN)
<--------------- FOO_ERROR(source=fred, destination=alice, id=4, state=CONTINUE)
---------------> END_REQUEST(source=alice, destination=fred, id=4, state=END)
-------> END_REQUEST(source=alice, destination=bob, id=3, state=END)
(We could possibly omit the source_name in Response/Error message types,
because the Requestor already knows the peer from sending out the Request;
but for sanity, maybe rather always keep both names.)
Does this make sense / am I missing something?
- And we need to make sure that we can freely re-use the session_id IE on the
E-interface without conflicting with the Supplementary Services session_id /
without confusing the gsup_client API.
Please create issues on osmocom.org for these tasks as you see fit.
There is no pressing need yet to get this done *right now*, I have yet to
complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it
would be great to just build on working API once I need it.
I would be super grateful if you could relieve me of the burden of spelling out
these details. From the meetings I assume that sysmocom agrees; please manage
that, too, and let me know if any other tasks are more important...
Thanks!!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hello, dear Osmocom community,
Has somebody been looking at the issue https://osmocom.org/issues/1977 recently?
Or, in other words: has anybody got the 3G Packet Switched network
working in Osmocom reliably?
I am looking for hints that might help me to fix the issue or for
possible hacks/fixes if somebody has implemented something like that
in their setups.
Thank you!
Kind regards, Mykola
I have now moved the Limesdr mini back and forth between the Orange Pi
Zero and a Supermicro
(i386). On the Pi Zero I get the following on the console:
Tue Jan 22 20:36:43 2019 DMAIN <0000> Transceiver.cpp:1039
[tid=3043130448] ClockInterface: sending IND CLOCK 321960
Tue Jan 22 20:36:44 2019 DMAIN <0000> Transceiver.cpp:1039
[tid=3043130448] ClockInterface: sending IND CLOCK 322176
Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448]
chan 0 recv buffer of len 2500 expect 894a7c got 895e68 (895e68) diff=13ec
Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448]
chan 0 recv buffer of len 2500 expect 895440 got 897024 (897024) diff=1be4
Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448]
chan 0 recv buffer of len 2500 expect 895e04 got 897de4 (897de4) diff=1fe0
The DDEV message can continue for a long time, and typically then ends
with the transceiver exiting. It can however sometimes recover, and the
first message of
recovery is a IND Clock message, after that the transceiver restarts,
and all is again well for some undefined time.
I have followed your suggestions, and rebuilt --with-neon-vfpv4 , and I
have enabled debugging. If I understand correctly, the function is
readSamples, and
is the actual input from the Lime rx. The length seems always correct,
since I do not get that log entry, but rather that the time has
"slipped", i.e.
the LMS api has not delivered anything for "diff" time, or the timestamp
received has "jumped" in the Lime.
This indicates to me that this specific arm cpu in combination with
limesdr mini and the software "drops data". I will gladly try to debug
or narrow this down,
but ask for some suggestions on how to proceed. One thought is to save a
timestamp each time through readSamples and compare to some constant
to determine that the problem is NOT that we are unable to read as fast
as required. reading 2500 samples would take 2.3 mS if I understand
this, so we need
to cal readsamples at about this rate....
Possible causes could be something *else* locking out the program.