Hi all,
After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error:
/pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto
Insert card now (or CTRL-C to cancel)
Autodetected card type fakemagicsim
Generated card parameters :
> Name : 26C3
> SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000
> ICCID : 8949262427518313026
> MCC/MNC : 262/42
> IMSI : 262422461512085
> Ki : 7b74741a1ee14337ec23f9ab92a13648
> OPC : ccd867d60797d8d45354a51b3ef568ff
Programming ...
Traceback (most recent call last):
File "./pySim-prog.py", line 530, in <module>
card.program(cp)
File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program
self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3))
File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary
return self._tp.send_apdu_checksw(pdu)
File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
RuntimeError: SW match failed ! Expected 9000 and got 9804.
I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code.
Thanks a lot and best regards
Martin
> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
Hi all,
This patch set adds to libosmocore an optimized Viterbi decodeer for
architecture specific (Intel SSE) and non-specific cases. The
implementation covers codes with constraint lengths of K=5 and K=7 and
rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup
from the current implementation is in the range of 5 to 20 depending on
the processor and code type. API is unchanged.
Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes
from osmo-bts are included. Further tests for AWGN bit-error-rate
and benchmarks can be found in the following repository.
https://github.com/ttsou/osmo-conv-test
Here are some examples.
Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts.
$ ./conv_test -c 2 -e -r 5 -i 100000
=================================================
[+] Testing: GPRS CS2
[.] Specs: (N=2, K=5, non-recursive, flushed, not punctured)
[.] Input length : ret = 290 exp = 290 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] BER tests:
[..] Testing base:
[..] Input BER.......................... 0.042443
[..] Output BER......................... 0.000006
[..] Output FER......................... 0.001350 (135)
[..] Testing SIMD:
[..] Input BER.......................... 0.042460
[..] Output BER......................... 0.000005
[..] Output FER......................... 0.001240 (124)
Timed AFS benchmark with 8 threads and 100000 bursts per thread.
$ ./conv_test -b -c 10 -j 8 -i 100000
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
-TT
This commit adds this predicate function which can be used to
avoid the execution of code if a certain log level is not enabled.
The function will only return 0 (false), if it is sure that a logging
call for the same facility and level will not produce any output.
This safety criterion shall ensure, that no logging output is lost
due to the use of this predicate as a guard. On the other hand, even
if the predicate returns != 0 (true), no logging output might get
generated by a similar logging command.
Note that the current implementation is not focussed on performance,
which could be improved by using a lookup table instead of iterating
through every target.
Sponsored-by: On-Waves ehf
---
include/osmocom/core/logging.h | 1 +
src/logging.c | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index 1c159d0..290b33d 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -198,6 +198,7 @@ void logp2(int subsys, unsigned int level, const char *file,
int line, int cont, const char *format, ...)
__attribute__ ((format (printf, 6, 7)));
int log_init(const struct log_info *inf, void *talloc_ctx);
+int log_check_level(int subsys, unsigned int level);
/* context management */
void log_reset_context(void);
diff --git a/src/logging.c b/src/logging.c
index 876964a..c7b1999 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -865,4 +865,43 @@ int log_init(const struct log_info *inf, void *ctx)
return 0;
}
+/*! \brief Check whether a log entry will be generated.
+ * \returns != 0 if a log entry might get generated by at least one target */
+int log_check_level(int subsys, unsigned int level)
+{
+ struct log_target *tar;
+
+ if (subsys < 0)
+ subsys = subsys_lib2index(subsys);
+
+ if (subsys > osmo_log_info->num_cat)
+ subsys = DLGLOBAL;
+
+ /* TODO: The following could/should be cached (update on config) */
+
+ llist_for_each_entry(tar, &osmo_log_target_list, entry) {
+ struct log_category *category;
+
+ category = &tar->categories[subsys];
+ /* subsystem is not supposed to be logged */
+ if (!category->enabled)
+ continue;
+
+ /* Check the global log level */
+ if (tar->loglevel != 0 && level < tar->loglevel)
+ continue;
+
+ /* Check the category log level */
+ if (tar->loglevel == 0 && category->loglevel != 0 &&
+ level < category->loglevel)
+ continue;
+
+ /* This might get logged (ignoring filters) */
+ return 1;
+ }
+
+ /* We are sure, that this will not be logged. */
+ return 0;
+}
+
/*! @} */
--
1.9.1
Hi,
here are some patches that I produced while compiling some osmocom
projects and its dependencies on a new box.
Most of them are trivialities that prevent compiler warnings.
The patch for openbsc though fixes a bug that prevents the build when
libgtp from openggsn is not present on the system.
Kind regards,
-Alex
Hi,
I like code-review around mailinglists (mostly everybody can read and learn from
comments or code), it shows that people collaborate and that we move forward.
What I don't like about the current workflow is that we need to manually close things
in patchwork after applying/rejecting/ignoring a patch and that to see if it compiles and
works are done after the review and by the person that applies the changes.
In other projects I have used Gerrit and besides it being a Java monster found it
quite okay to use. One strength is that one can directly push the changes for a branch
for review, the other is that Jenkins and Gerrit can collaborate. This means that after
a commit is pushed make, make check, make distcheck can be executed. Comments
will always be attached to a line and not be lost due me quoting and removing parts
of the mail.
What I am not sure about:
* How do the email notifications look like? E.g. do we just get a "Somebody has
commented" mail or do we get diff + comment sent here? In OpenOCD I see there
is an email with the diff[1] but no mail with the comments.
* Shall we support direct pushes? I think specially in the beginning we should but
the branch name for that would change.
* A change that impacts libopenbsc+OpenBSC is difficult to represent. It would break
"the" build but I don't see any other way.
Is there enough consensus to give it a try?
holger
[1] http://sourceforge.net/p/openocd/mailman/message/34646766/
Hi list,
after a code review session between Holger and me, I've now merged the
gtphub branch to master, completely. You can't miss the endless sequence
of commits that have just come in on master.
This is not to say that the code is glorified beyond doubt.
Please do review, if you can spare the time.
Thanks,
~Neels
--
- 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: Holger Freyther, Harald Welte