Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Gerard Lawrence Pinto gerardfly9 at gmail.com
Wed May 31 03:53:56 UTC 2017


Hi Harald,

No problem. I totally understand thanks for the reply!

> So I suggest we move the existing mncc-python repository into gerrit,
> and then you can submit whatever you think is missing in mncc-python?

Yes, please thanks! As far as I remember there was just 1 issue
when I used mncc-python with OsmocomBB on real network.
I can confirm this again and push the fix there if it still exists. So you
can verify it accordingly.

> A general suggestion (independent of Osmocom): Please always put license
> information in your code.

Ok I wasn't aware of this protocol. I read and understood that I need to
include GNU PL
and cite if a 3rd party library is used (also check its license conditions)
If I'm contributing to an existing then keep the original license intact
(also check its conditions)

> If you work on existing code, then please properly clone the original
> repository and then add your patches on top of it.

Yes, my apologies I did clone from git. However I must have messed up.

> The way how to properly solve this (normally) is that Layer1 is sending
something like "ready to send (RTS) indications" to Layer2
> L1CTL doesn't have this so far,
> Please also keep future osmocom-bb related questions to the
baseband-devel list, thanks!

Very interesting reply, thanks!
Sure baseband-devel list, I was thinking the same that it should have been
there,
so other developers would be aware of it.

> I'm happy to review it once there is a repo based on the original one
> with change sets to review.  We can also move osmo-sim-auth to gerrit so
> you can submit your patches there.

Yes, please thank you! Sorry about not maintaining history.

I have just added other SIM card related API's like fetch - IMSI, LAI, ICCID
write LOCI etc.
(A full fledged sim reader/writer of a SIM card)
Let us keep it in osmo-sim-auth for now.

If it is accepted by Osmocom, then later can be merged with Pysim with a
different executable?
(Although it was built for programmable SIM card - agreed) We can discuss!

Thanks,
Gerard

On Mon, May 29, 2017 at 12:51 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Gerard,
>
> sorry for the delayed response, sometimes there are simply too many
> tasks and mails to handle :/
>
> On Fri, May 19, 2017 at 10:28:56PM -0700, Gerard Lawrence Pinto wrote:
> > Congrats on OsmoCon 2017!
>
> thanks!
>
> > I have been working with OsmocomBB, osmo-sim-auth, mncc-python
> > projects in Osmocom.
>
> great.  The important part is now to make sure those changes don't live
> somewhere out there but to think how they can be merged mainline!
>
> > To begin with I have committed:
> > I) MNCC with OsmocomBB - *https://github.com/
> GerardPinto/call-control-mncc-sap
> > <https://github.com/GerardPinto/call-control-mncc-sap>* (Has both
> > implementations in Python and C + Tested voice with gsm-fr with gsm audio
> > file - works great).
> >    -  Some of which can be committed to mncc-python? (In order to support
> > MNCC with OsmocomBB too) Although, Harald told me it was built for
> OpenNITB
> > - I'm not sure, the relevance of this contribution to this repo?
>
> MNCC should be virtually the same, whether on OsmocomBB or on OsmoNITB
> (or now OsmoMSC).  Let's avoid having different implementations and
> different repositories.  At least regarding the python code, please
> submit your changes to mncc-python
>
> We generally try to avoid fragmentation of code but want to have one
> implementation of a given functionality within the project.  So what's
> needed is the knowledge of what exactly is missing or needs
> modification/improvement in mncc-python, not another implementation with
> unclear status on what are advantages/disadvantages of either of them.
>
> So I suggest we move the existing mncc-python repository into gerrit,
> and then you can submit whatever you think is missing in mncc-python?
> How does that sound?
>
> A general suggestion (independent of Osmocom): Please always put license
> information in your code.  Otherwise it is not clear if anyone is able
> to use it (and under what terms).
>
> > *Issues faced*: File: l23api.c |  function: l1ctl_rx_traffic_req()
> > 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The
> DAC,
> > ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 =
> > 456.
> > So Layer23 sends 4 - 114 bits into the queue to Layer1 in function =>
> > l1ctl_rx_traffic_req
> > *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC])
> > if num > 4 dropping traffic frame. (114 x 4)
> > The code above indicates if queue has any (114 x 4) bits drop the
> incoming
> > voice request.
>
> Well, GSM is a TDMA system and everything has to happen with regard to
> the TDMA clock as defined by the BTS (clock master).   So you cannot
> send voice frames faster than the TDMA clock is transmitting them.
>
> > *My Question is*: If I happened to send voice packets 33 bytes really
> fast.
> > There should be some kind of buffer rather than a check (Code) and drop
> > frame? - OR this case can never happen?
>
> The way how to properly solve this (normally) is that Layer1 is sending
> something like "ready to send (RTS) indications" to Layer2, and Layer2
> then knows it has to send another frame.  This way, the timing is
> defined by L1.  However, as there is latency between L1 and L2 (serial
> line, operating system scheduling, ...) there actually needs to be a bit
> of a buffer or an "advancement" of the RTS indications to compensate for
> that.
>
> L1CTL doesn't have this so far, but it would of course be appreciated if
> somebody would make it more robust and contribute related patches.
>
> Please also keep future osmocom-bb related questions to the
> baseband-devel list, thanks!
>
> > II) osmo-sim-auth with added other SIM related API's (still needs code
> > clean up, SIM response check, code re-usable, README.md etc,)
> > * https://github.com/GerardPinto/osmo-sim-auth
> > <https://github.com/GerardPinto/osmo-sim-auth> *
> >  - I did check out PySIM (I think I can add some code to the existing
> > repository, with your permission).
>
> If you work on existing code, then please properly clone the original
> repository and then add your patches on top of it.  That way one can
> browse the commit log and clearly look ad individual patches.  I'm
> unable to figure out what you did by looking at your repository, as you
> appear to have imported an unknown version of osmo-sim-auth without
> cloning the original repository and keeping history.
>
> > Could you please let me know if my osmo-sim-auth repo? If it is correct
> to
> > combine with PySIM, with the changes done below?
>
> I'm happy to review it once there is a repo based on the original one
> with change sets to review.  We can also move osmo-sim-auth to gerrit so
> you can submit your patches there.  But in order to do that, you would
> also have to do a proper clone of the original repo and implement your
> changes as commits on top.
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170530/c5fba535/attachment.htm>


More information about the OpenBSC mailing list