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