Hello.
Attached is a trivial patch which makes example config for libosmo-sgsn actually usable.
Most likely it was typo.
--
best regards,
Max, http://fairwaves.ru
Hi!
I've been hacking away a bit on a new library 'libosmosim' whihc is
scheduled to become part of libosmocore. In fact, as the automake
integration has been cleaned up, I'll probably merge it master any day
now.
The idea of this library is to
* understand the EF/DF hierarchy if GSM SIM, ETSI UICC and 3GPP USIM
* provide encoding and decoding routines for at least the most important
EFs
* decode the binary data into a generic data structure which can be used
by some form of a GUI application
* be able to re-encode from the generic parsed structure into the
binary form, possibly after modification from the UI
* be able to transact APDUs via T0 and T1 on PC/SC and other reader
interfaces, e.g. the OsmocomBB SIM interface
So the primary purpose of this is to be able to have a tool for
meaningful (human-readable/writable) modification of all files on a
programmable SIM card, such as the sysmoSIM-GR1 (and other cards where
you have the ADM PIN that gives you write permission).
Other useful purposes on the horizon of the library could be:
* implementation of a generic SIM/UICC/USIM simulator based on
user-created input, or based on 'ripped' SIM cards (well, you have to
provide the key in some way).
The current status is still quite experimental, but you can already see
the major parts:
* mapping of APDU and TPDU (only T=0 so far) on to 'struct msgb
struct osim_file_ops
encode and decode callbacks for a given file
struct osim_file_desc
node in the hierarchical description of filesystem tree
struct osim_decoded_data
the runtime representation of a decoded file:
struct osim_decoded_element
one decoded element in a decoded file
struct osim_card_sw
status + bitmask + human readable description
struct osim_card_profile
full description profile of card, including filesystem
hierarchy, status words and card-specific commands
struc osim_reader_hdl
represents a card reader (currently a slot in a reader,
not sure really how to represent multi-slot readers like
sim-banks yet). primarily consist of osim_reader_ops
struc osim_card_hdl
representing a card inside a reader
struc osim_chan_hdl
currently just a dummy. intended for logical channel support
most of the existing code is in src/sim/*.c, while some
not-yet-cleaned-up example code is in utils/osmo-sim-test.c. There are
gaps everywhere all over the place, and I think it will take quite some
time to fill those gaps.
Current roadmap:
* properly integrate all parts, so with a single call you can read in
the tree of all EFs of a card into their in-memory representation
* verify that the APIs for encoding/decoding functions work the way
they are before writing 'all' the EF decode/encode routines
* add more decoded element types, such as location area codes and the
like
So if you survived this mail until this point, I think you are a prime
candidate for contributing some code. Let me know if you're interested
in helping out.
Regards,
Harald
--
- 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)
Hi Harald,
I can't tire of congratulating and the community for the great work you are
doing in creating a free world in your own capacity! I thank you.
Meanwhile, I would like to know a few things:
1. Is sysmoBTS capable of operating in MultiARFCN? Is multiARFCN
implemented in OpenBSC and if so how does one go about configuring it.
2. Also after the successful implementation of CSD, are there plans for PTT
over Cellular (PoC)?
Hi all!
This is the announcement for the next Osmocom Berlin meeting.
Sept 05, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin
There is no formal presentation scheduled for this meeting.
If you are interested to show up, feel free to do so. There is no
registration required. The meeting is free as in "free beer", despite
no actual free beer being around.
Regards,
Harald
[p.s.: I myself will not be able to attend tonight, but I'm sure you
will be able to do just fine (or even better?)]
--
- 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)
hi,
after having solved an LCR issue, i patched rtp_proxy.c the same way,
because it has the same issue.
1. when next_udp_port (in rtp_socket_bind) reaches 0xfffe, the bind
process will fail next time.
2. if rtp_sub_socket_bind of rtp socket succeeds and rtp_sub_socket_bind
of rtcp socket fails, the rtp socket must be re-created, because it
cannot not be bound again to the next higher port.
3. the port range will not wrap arround and start at 0, but at
RTP_PORT_BASE. (after reaching RTP_PORT_MAX)
andreas
As already mentioned, the Osmocom Meeting will
take place this Saturday, 1.9.2012 at 10:00.
Three people have confirmed that they will come,
I have send them an email with the location details.
Harald is not yet sure if he can attend.
A few suggestions for the meeting:
- I will run a GSM-1800 network with my test license so
you can try out OsmocomBB. If you are interested to
do so please bring your Osmocom phone plus Laptop with
the already installed OsmocomBB software.
- We can do some experiments with SIMtrace if there is any
interest.
- There should still be enough time for other things, we
can decide what to do during the meeting.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
All,
Apologies if this is the wrong mailing list for this question. If so,
please redirect me to the appropriate Osmocom list. Thanks!
I'm having trouble with some older 2G cellular modules. When they initiate
GPRS, the GPRS Attach Accept response from the SGSN seems to be dropped on
the floor. I thought this was because the inbound TLLI generated by the ME
was not included in the subsequent response. However, I verified that the
LLC correctly generates the response and attaches the TLLI. I'm not quite
sure why these particular 2G modules are not receiving the response as the
message seems to be correctly submitted from the SGSN to the BTS.
The result is that the GPRS state will get "stuck" on the ME side, which
will keep attempting to Attach until it gives up and issues a Detach
message (under the same TLLI).
Can anyone clue me in on what potential issues may be caused by this ME and
how/if I can patch this problem in the SGSN?
Thank you,
D
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
Hi,
This is the second version of the libosmo-abis patchset. Mostly
aiming to improve robustness and fix leaks in error paths.
I have tried to address all Holger comments, I leave two things
for my TODO list:
1) automate testing via automated testing while compilation
2) check the bfd->fd = -1 to make sure we need it in all cases
I have also intensively tested (although it was quite manual)
this changes with the IPA BSC/BTS tests, running valgrind to
check for leaks.
If you find any issue or you think it's OK, please ACK/NACK.
Thanks.
Pablo Neira Ayuso (13):
ipa: fix missing set of write_cb for IPA client connection
ipaccess: fix leak of e1inp_line
tests: e1inp_ipa_bsc_test: fix crash
ipaccess: improve error handling
tests: e1inp_ipa_bts_test: fix compilation warnings
lapd: use C99 structure initialization for profile templates
input: dahdi: use logging facilities instead of fprintf and stderr
input: dahdi: replace exit by return
input: add generic PCAP interface for LAPD
tests: fix CPU suckup e1inp_ipa_bts_test after test finish
tests: e1inp_ipa_*_test: add signal handling for process termination
tests: e1inp_ipa_*_test: fix leak of msgb in ->sign_link path
ipaccess: fix leak of IPA control messages in the BTS side
include/Makefile.am | 2 +-
include/osmocom/abis/lapd.h | 1 +
include/osmocom/abis/lapd_pcap.h | 11 ++
src/Makefile.am | 1 +
src/e1_input.c | 1 +
src/input/dahdi.c | 54 ++++++----
src/input/hsl.c | 3 -
src/input/ipa.c | 3 +
src/input/ipaccess.c | 210 ++++++++++++++++++++++++++------------
src/input/lapd.c | 66 +++++++-----
src/input/lapd_pcap.c | 159 +++++++++++++++++++++++++++++
tests/e1inp_ipa_bsc_test.c | 26 ++++-
tests/e1inp_ipa_bts_test.c | 31 +++++-
13 files changed, 443 insertions(+), 125 deletions(-)
create mode 100644 include/osmocom/abis/lapd_pcap.h
create mode 100644 src/input/lapd_pcap.c
--
1.7.10.4
