GGSN p-t-p address?

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/.

Mychaela Falconia mychaela.falconia at gmail.com
Wed Aug 22 18:06:13 UTC 2018


Hi Keith!

> So, I decided to carry out a similar simple test, by putting my local
> operator SIM into the modem.
> I still got the 192.168.100.101 p-t-p address. Given that this happens
> on OpenWRT and Windows, although I didn't bother test windows with the
> local operator, I would have to assume that in my case, it's coming from
> the modem, as Harald suggests.

I wonder, is it possible for the GGSN to either provide or not provide
the far end IP address?  I wonder if the modems pass on the far end IP
address provided by the GGSN if there is one, and make up their own
placeholder otherwise?  I suppose I won't know until I take the time
to study the implementation code I got from TI, and I don't know when
I may be able to find the time to do that...

I wish I could send you one of my FreeCalypso modem boards so you
could test it against your Osmocom network - it would be the first-
ever GPRS connection made between a free, fully understood modem
implementation and a free, fully understood network - but I don't have
any boards left: all V1 boards are sold out, and I need about 3000 USD
to order the PCB fabrication of V2 boards.

> Can we see diagnostic output on gprs negociation on the freecalypso side?

By default only L1 emits voluminous debug output, not any of the upper
protocol stack layers, but you can send developer commands to the
running fw over the second UART (the same one on which the debug output
is, not the one that carries AT commands and PPP) to enable more
verbose debug traces.  However, you cannot enable "everything", as the
trace output mechanism will be overwhelmed and you will be lost in the
noise, instead you need to study the code first, get a good grip on
its architecture, and then selectively enable the traces of interest
to whatever you are investigating.

> Does it give us an "insight" into what this TI baseband is doing?

"What this TI baseband is doing" - just to be sure that everyone
understands the context, the hardware and the DSP black box only
receive and transmit bursts, nothing more; everything above the
physical layer is done by software running on the ARM7 processor, and
we have the complete C source for that software, no blobs.  It is a
*different* version of TI's upper level protocol stack code than the
one that was used by Openmoko - the latter had blobs with no
corresponding source.  I am using a newer version of TI's upper level
protocol stack code that was originally supported by TI only on their
LoCosto chipset, which is much less understood by the community than
the good old Calypso - so I backported that code from LoCosto to
Calypso, and then built my own Calypso-based board to run it on.
Motorola C1xx phones that are used by OsmocomBB aren't good enough for
this purpose: I really needed two UARTs (one for AT commands and PPP,
the other for development and debug), whereas those Motorolas only
have one usable UART.

People should also get over the incorrect notion that it is all TI's
stuff and that I am merely pirating and remarketing it.  The FC
Magnetite repository alone (the one from which I make stable production
builds) has more than 500 commits since the initial import, it took
349 commits in another repository to reconstruct the L1 code (watch my
REcon Montreal 2017 video for the details), another 806 commits across
several repositories to develop various supporting tooling, and all of
that was *after* my initial attempt (freecalypso-sw) which I concluded
was the wrong approach; that "rough first attempt" freecalypso-sw
repository got 1034 commits at the time of its retirement.  There is
no practically available hardware on which one could run any of TI's
original code versions without my changes, and the only hardware that
*is* practically available (my development board, called FCDEV3B)
requires FreeCalypso firmware to function usefully, not any of the
historical pre-existing versions from TI or from other companies.

TI has not provided one bit of support for any of this software or for
the silicon needed to run it since 2009, all development after that
date (almost a decade) was done by me and not by them.  I am not
merely "hacking" this code, I am striving to maintain it, support it
and continue further development of it no worse than TI did in their
peak days.  However, the code base is huge, and being just one person
working on it in my spare time without commercial funding, I can only
do so much - there are many parts of the code which I haven't studied
yet because the code "just works" and I haven't had a need to delve
into it yet - most of the GPRS code is in this category.

I was actually quite amazed that the GPRS code just worked out of the
box when I backported the new TCS3/LoCosto version of G23M to the
Calypso and made it compile in my Magnetite build environment.  This
new code version differs from the old one which TI officially supported
on the Calypso: they added a new protocol stack component called UPM
(User Plane Manager), and it appears to originate from TI's dual-mode
GSM+UMTS (3G) protocol stack - but it also has a 2G-only mode when no
UMTS protocol stack components are present, and this 2G-only UPM is a
required component of the FreeCalypso hybrid (previously TI LoCosto)
protocol stack for GPRS.

Osmocom has done a magnificent job of bringing to the world a FLOSS
implementation of the network side of GSM, GPRS and UMTS, but there
are no practically usable Osmocom offerings for the mobile side -
every one of those awesome Osmocom 2G or 3G networks out there is
still serving end user phones and modems that are 100% closed and
proprietary.  It is high time for the user equipment side to be freed
too, and if Osmocom is not doing it, then someone else will.  At the
present time I am not aware of anyone else other than FreeCalypso
offering any kind of practically usable cellular end user equipment
that is anything other than an impenetrable binary blob that is also
tivoized most of the time.

M~

P.S. I wish I could meet you all at OsmoCon in October, but it won't
be possible even if someone volunteered to pay for my airfare: I would
need to get a U.S. Travel Document (aka Re-entry Permit) in order to
travel outside of USA+Canada+Mexico territory, and that process would
certainly take longer than the two months or less between now and
OsmoCon.  However, if there is any other conference or gathering
coming a little further out, and if someone would like me to come to
that one and would cover my flight, please let me know and I will
start the months-long application process to get my travel document,
which will then be good for 2 y.



More information about the OpenBSC mailing list