Re: Does anyone from the community want the airprobe.org domain?
Hi Domi, > Thanks for the offer of hosting content on osmocom infra, I think that’s a > good idea. > I would still like to keep the original domain, for sentimental reasons I > guess, so what I’d propose is that I take ownership, pay the fees and for now > just enable a redirect to the page hosted at Osmocom infra. > Maybe later I decide to use the domain for something else, but the osmocom > page would still be up, providing info and serving up a trip down memory lane > for people interested. that sounds good. I'll follow-up by private e-mail -- - Harald Welte https://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Does anyone from the community want the airprobe.org domain?
Hi Domi,
On Thu, Jan 18, 2024 at 11:32:37PM +0100, Tomcsanyi, Domonkos wrote:
> If nobody else wants it I would be happy to preserve it, [...]
>
> I’d definitely try to host some info on it about the original project
> (possibly even get back all redmine pages from archive.org) and maybe use it
> for something else, still mobile networks + security related - nothing
> concrete in my head right now, just some general direction.
I think I'd be more than happy to offer some hosting space (container,
lxc, whatever) on the osmocom infrastructure if anyone wants to create a
page with historical data on/about airprobe. This way, chances are high
it will remain active/running for as long as the rest of osmocom does.
I just don't feel particularly compelled in paying annual domain
registration fees for yet another domain, especially if that domain was
not used "back in the day" and there are hence no links/URLs to
preserve.
So IMHO the great work would be collecting information, but we could do
that just as well under (e.g.) airprobe.osmocom.org without incurring
extra cost.
In any case, if you want to take ownership of airprobe.org, it is of
course entirely up to you to decide what you'd want to do there.
Whether you'd want to host that on your own or on osmocom
infrastructure.
Regards,
Harald
--
- Harald Welte https://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Does anyone from the community want the airprobe.org domain?
Hi all, I was approached by the person currently holding the [unused] airprobe.org domain name. I guess it was at some point registered and intended to be used for the project (back in the pre-osmocom days). As far as I know it was never actually used for that. So the question is now if anyone wants to get that domain transferred in order to do something useful with it, or whether the current registrant should simply let it expire? Regards, Harald -- - Harald Weltehttps://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoDevCall on Nov 15, 2023: Calypso history: From TI to FreeCalypso to USA PSTN
Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: (today) November 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @falconia will be presenting on Calypso chipset history and development boards, from TI to FreeCalypso This meeting will have the following schedule: 20:00 meet + greet 20:10 topic as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Powering GSM MS from USB
Hi Mychaela, as usual: Sorry for the late response. On Sun, Oct 22, 2023 at 03:40:49PM -0800, Mychaela Falconia wrote: > But what would be the right way to support 2 A current spikes during > GSM Tx bursts? I reason that a large capacitor will need to be placed > on the output of the 3.5V step-down regulator, one that will store > enough energy to feed the PA during that hungry burst - any thoughts > as to which type and size of capacitor would be most appropriate here? In the past several people have powered calypso phones that way, e.g. via https://wiki.cuvoodoo.info/doku.php?id=osmotoserial I'm not sure if any of those people ever looked at the transmitted spectrum or envelope and verified it passes conformance specs, though. I would go about this experimentally: Take a few large (1000uF or larger) electrolytic capacitors from a box, configure the MS to transmit at 900 MHz at full RF power and look at the DC input voltage at the PA during the burst transmission, comparing it from battery operation with USB operation. Or, even better, if you have a Racal 6103 or equivalent: Look if the power envelope of the transmitted bursts is working out. You could also start with theory: calculate how many coulombs you'd need, etc. - but I'd find that tiresome and given the ESR/ESL and other real-world effects one would have to do the practical test anyway. One thing you will need for sure is some kind of USB-specific power circuit that limits the inrush current. The USB spec has a clear limit of how much capacitance a device may present to the host. It wasn't much, IIRC somewhere in the 10..100uF range. So you need to limit the inrush current. Furthermore, if you really want to be correct and ensure spec compliant operation, you actually must not draw more than 100mA until a descriptor with more current requirement has been selected by the USB host. > And the most important question, for people with more EE experience > than me, and/or people who have already considered this problem: is > this capacitor solution expected to work, or is the problem intractable > in the sense that a USB-powered GSM MS, with the USB host limiting to > 500 mA, will never be able to produce proper GSM Tx bursts at max power > without tripping overcurrent shutdown on the USB host port? I would expect it to work, if the capacitor is reasonably large and fast. -- - Harald Weltehttps://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Osmocom discourse as alternative to mailing lists
Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Weltehttps://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: RFC: OsmoDevCall restart: Your input required
Hi again, I initially wrote: > The polls are open until October 21st, 2021. As the turn-out has been rather high already, I think we have a clear winner: * monthly schedule (92.5% approval) * 20:00 CET/CEST at (73.8% approval) * Wednesdays at (89.1% approval) So the new slot for OsmoDevCall will be Wednesdays 20:00 CET/CEST. This puts the first OsmoDevCall as per the new schedule at next wee Wednesdays: October 19, 2022. Can't wait to get this re-launched. Given the lower (monthly) interval, I am planning to split the retronetworking related talks into a separate event series, independent of OsmoDevCall. So OsmoDevCall will stay focused mainly on mobile communications related topics. Looking forward to meeting you again next week. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
RFC: OsmoDevCall restart: Your input required
Dear Osmocom community, your input is required in order to tune the re-launch of the OsmoDevCall talk series. One of the complaints before the suspension in Summer this year was that the "Friday night 8pm CEST" timeslot was not exactly ideal for several people. Finding a common denominator might be difficult, given that Osmocom is a dayjob for some, a hobby for most, and we're of course not all in the same time zone or even continent. So let's try to run a couple of polls to figure out: * What is the best day of the week for OsmoDevCall? https://bitpoll.de/poll/CEQnaQKEvO/ * What is the best time of day for OsmoDevCall? https://bitpoll.de/poll/59dgmzOocT/ * What is the best frequency of OsmoDevCall https://bitpoll.de/poll/8jyuRJB6Hb/ The polls are open until October 21st, 2021. I would appreciate a high turn-out so we have a good representation across our community to make an educated decision about the schedule of futur events. Can't wait to re-start OsmoDevCall! Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: New attack ?
Hi Bastien, please try to avoid spamming the mailing list with lots of single-line responses on a single day, thanks. On Mon, Aug 22, 2022 at 07:53:00PM +0200, Bastien Baranoff wrote: > https://github.com/bbaranoff/telco_story/blob/main/README.md What you are describing is a classic GSM man-in-the-middle attack, combined with a 4G->2G downgrade. I don't see what is new here. It's how MITM on 2G has operated basically forever: You can just 1:1 forward the authentication, but need to crack the Kc before you can talk encrypted from your virtual MS to the real BTS. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
migration of git.osmocom.org to gitea?
Dear Osmocom community, [please follow-up-to the open...@lists.osmocom.org mailing list, if there is any discussion, we don't want to drag it over tons of mailing lists in parallel] Back in February I was posting a related RFC, and now the migration is complete, at least for all externally visible aspects relevant to users and developers. I've tried to make it as backwards-compatible as possible, meaning that; * we do have https://gitea.osmocom.org/ by now * gitea is the primary system for all non-gerrit repositories (mostly projects outside the cellular network infrastructure), see e.g. https://gitea.osmocom.org/phone-side/osmo-qcdiag * gitea is a secondary/mirror for all gerrit hosted repositories (mostly projects within the cellular network infrastructure). Those repositories are marked as mirros with an icon next to the repository name, see e.g. https://gitea.osmocom.org/osmocom/libosmocore * https://cgit.osmocom.org/ renders the old cgit user interface for time to come * https://git.osmocom.org/ main page redirects to gitea * per-project https://git.osmocom.org/libosmocore redirects to the right gitea URL for each project (by means of a series of about 200 nginx rewrite rules). This also means that cloning from old https URLs remains working * cloning from the git:// URLs also remains working * deep links to individual commits, or to the /patch URL as used in our Dockerfiles for cache invalidation on source code change remain valid So this means that all existing links, search engines, read-only clones, etc. will continue to work for those repositories that were still created in the pre-gitea time. However, for developers with commit/push access to non-gerrit repositories, there are some changes: 1) you will neeed to create an account on https://gitea.osmocom.org/ - and register your SSH public key[s] there. Unfortunately due to a bug in redmine we cannot yet use the redmine OpenID provider, so you need to create a separate account. If you're missing permissions for certain respositories, please contact me by private mail or create an issue in https://osmocom.org/projects/osmocom-servers 2) you will need to change the git+ssh push URLs if you want to push to repositories *not* hosted on gerrit. I've attached a CSV file for the old vs. new URLs to https://osmocom.org/attachments/5148. You can change the URL in your .git/config files manually, or you can use the 'git remote set-url' command to do that. If something is not working as expected, please let me know. The main ticket for the gitea migration is https://osmocom.org/issues/5397 Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmoDevCon 2022 ?
Dear fellow Osmocom developers, more than a month later and the world is a completely different place once again. Given that the number of daily infections and deaths are again rising in Germany, I am rather happy that we didn't settle for a spring date in / around our usual April time frame. On Wed, Feb 02, 2022 at 08:28:41AM +0100, Harald Welte wrote: > > I have started a poll at https://dudle.inf.tu-dresden.de/TrmQAhYOWA/ > in order to understand whether there's a preference for a specific month, > and I'd like to invite everyone to state their preference in this poll > (can also be done anonymously). the poll has shown a clear preference for September. So if we are to hold an OsmoDevCon this year, it will definitely be in September. > The venue and format can of course also still be discussed. I would think > that having everyone in the same hotel would reduce the amount of contacts, > as not every participant meets different hotel staff, has to commute through > a city spending time with hundreds of other different people every day in > public transport or the like. This might of course increase cost, but I'm > sure > we can find a solution for that. I haven't really seen much feedback on that topic. I still like that idea, and the limited feedback I've seen was positive / neutral, so I think I'll continue to explore in that direction. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
RFC: migrating git.osmocom.org to gitea?
Hi all! [please follow-up-to the open...@lists.osmocom.org mailing list, if there is any discussion, we don't want to drag it over tons of mailing lists in parallel] Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody noticed the ticket or had any comments to it. So let me post this as RFC here on the mailing list: In the past, we had a gitolite/gitosis setup, which was fine in the early days of git, but it means that people cannot easily create new repositories, see who has permissions, and we cannot delegate ownership. Even updating SSH keys requires manual interaction of a sysadmin like me. I would therefore suggest to migrate git.osmocom.org to gitea[1] This would allow the following features: * users can self-create any number of personal repositories (like gitlab/github) * we can create 'organizations' along the line of reasonably independent osmocom member projects like op25, who can then manage their own repos/permissions/... * gitea can link to redmine wiki and redmine issue trackers (rather than using its own built-in) For those repositories hosted in gerrit (mainly CNI), we would still keep git.osmocom.org a read-only mirror, like we do it right now. For those repositories not hosted in gerrit, users/projects could then accept merge requests in gitea. Coupling this with 3rd party authentication via github/gitlab/etc should make it easier for the occasional contributor to submit changes. There is a downside, of course; A lot of repo URLs have to change. Most of our current repositories are at git.osmocom.org/project.git while gitea follows a git.osmocom.org/organization/project.git scheme. I'm not sure there is any way to help to mitigate this... Any thoughts, comments? [1] https://gitea.io/ -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmoDevCon 2022 ?
Dear fellow developers, given the rather unfortunate development of the pandemic both globally with Omicron, as well as particularly locally in Berlin, I decided to further postpone an on-site OsmoDevCon. At least the late April / early May time frame seemed unrealistic. Shifting the event further towards or into summer seems more realistic from a pandemic point of view, as experience over the past years has shown much lower infection rates then. However, there are of course holiday plans, etc. that might more likely conflict with OsmoDevCon at such a time. I have started a poll at https://dudle.inf.tu-dresden.de/TrmQAhYOWA/ in order to understand whether there's a preference for a specific month, and I'd like to invite everyone to state their preference in this poll (can also be done anonymously). The venue and format can of course also still be discussed. I would think that having everyone in the same hotel would reduce the amount of contacts, as not every participant meets different hotel staff, has to commute through a city spending time with hundreds of other different people every day in public transport or the like. This might of course increase cost, but I'm sure we can find a solution for that. One of the random thoughts I had was to use https://www.linuxhotel.de/ - a hotel + conference venue specifically dedicated to FOSS with plenty of outdoor space. However, it's at least a 35min cab ride from the closest airports (DUS, DTM) and about an hour from CGN. For people arriving long distance by car or train there's probably little difference compared to Berlin. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB releases
Hi Denis, On Tue, Jan 25, 2022 at 10:39:27PM +0100, Denis 'GNUtoo' Carikli wrote: > As I understand it is now possible to have a full software GSM stack in > software[1], with the stock osmocomBB since trx_toolkit target was > merged in OsmocomBB. trx_toolkit / fake_trx is used to connect the MS side OSmocomBB with the network side stack (osmo-bts-trx, etc.). > Many network side components have releases[2] and several distributions > already have part of the osmocom stack packaged[3][4]. Yes, this is primarily due to there being a lot of commercial interest and associated contributions, allowing various people working full-time on it for about a decade now. On the MS side, there has never been any significant commercial interest, and this is reflected in the situation that almost no code is being developed for a long time, and also very little maintenance and no releases. > Would the osmocomBB be interested in doing releases? Or is there > something that is preventing that from happening (lack of interest?, > lack of time/volunteers?, technical issues?). OsmocomBB is in sever lack of any form of contribution. There is no technical or other reason why there are no releases. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
lists.osmocom.org migrated to mailman3
Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoDevCall on Dec 10, 2021: osmo-dev and running TTCN3 test sultes locally + PFCP
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at December 10, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "osmo-dev and running Osmocom TTCN3 tests suites locally" by osmith 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
"OsmoDevCall" on Nov 25, 2021: Control/User Plane Separation (CUPS) + PFCP
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at November 25, 2021 at 20:00 CET (yes, Thursday instead of Friday this time!) at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "Control/User Plane Separation (CUPS) + PFCP" by laforge 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
"OsmoDevCall" on Nov 12, 2021: icE1usb in practice
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at November 12, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "E1 / TDM / PDH / SDH basics" by laforge 20:30 presentation "icE1usb in practice" by tnt later USSE: unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmoDevCon 2022 ?
Hi Kevin, On Fri, Nov 05, 2021 at 02:18:14PM +0100, Kévin Redon wrote: > I'm also happy to help with the recording and streaming of the public talks > for those not able to join on site. thanks for that, as usual. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoDevCon 2022 ?
Dear fellow Osmocom developers, as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021, trying to compensate it at least to some extent with our OsmoDevCall every two weeks. The COVID-19 pandemic is far from over, and we don't know what the upcoming winter season will bring. Nevertheless, I think it would be a good idea to start a discussion of whether we should plan for an OsmoDevCon in 2022. I personally would say let's plan for the usual late April 2022 time frame, and if the pandemic situation deteriorates, we can still cancel it with something like one month lead time. I would also personally suggest to limit attendance to people who are fully vaccinated, and in addition do a self-test for all participants every morning. In terms of venue, we might also consider to move to a venue that allows better ventilation. Irrespective of the above we can also bring the air filters from the sysmocom office. So with that as an input statement, I would like to hear your opinion on the above proposals. Who would want to attend? Any complaints against the "vaccinated only plus daily self-tests in the morning" approach? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: libmobile.a(mncc_sock.o) undefined reference
On Sat, Oct 16, 2021 at 12:02:44AM +0300, Mario Lucas wrote:
> I am having following error during ‘make’ osmocombb:
your host-side libosmocore is too old.
osmo_fd_{read,write}_{enable,disable} are part of libosmocore >= 1.5.0,
while you have 1.4.1
So either you need to upgrade libosmocore, or downgrade osmocom-bb.
--
- Harald Welte http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on September 24, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at September 24, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "ISO 7816 smart card interface FPGA softcore" by tnt 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: osmo-bsc default config file time-slot TS0 configuration CCCH+SDCCH4 understanding
Hi Mario, On Fri, Sep 10, 2021 at 11:40:43PM +0300, Mario Lucas wrote: > Could you please advise me based on what logic (how) can i decompose logical > channel configuration CCCH+SDCCH4 which is mapped on TS0… ? See the diagram e.g. at https://www.rfwireless-world.com/Terminology/GSM-combined-channel-configuration.html for the 51-multiframe in a combined CCCH situation, for both downlink and uplink. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Phone without a physical sim to connect to network
Hi Mario,
On Sun, Aug 29, 2021 at 03:40:19PM +0300, Mario Lucas wrote:
> I have a running BTS (based on SDR) and i can connect my phone to my network…
> do / learn some operations…
> I have a couple of sim cards and each time i want to connect to network with
> different sim i have to switch of mobile remove previous sim put new one etc
> etc ….
>
> Is there an application that will be running on PC and connected to my phone
> which will a kind of simulate sim and connect my phone to my network ?
> Avoiding me each time physically remove previous sim put new one etc etc …
in theory you could emulate the full sim card and do some software
integration to combine https://git.osmocom.org/softsim/
with the card-emulation ('cardem') mode of the simtrace2 firmware.
more practical / complete, without additional software develpoment, you can
use multiple smart card readers for your various SIM cards, and use osmo-remsim
+ simtrace2 cardem.
Howver, in reality you will still need to restart your phone as every time the
sim changes, everything needs to be re-read from it. For most phones entering
and leaving airplane mode also works.
> Also another question — is there a «search» option in the archives :
>
> http://lists.osmocom.org/pipermail/openbsc/
> http://lists.osmocom.org/pipermail/baseband-devel/
unfortunately not. We are considering a migration to mailman3, whose new
list archiver 'hyperkitty' provides this feature. but it's not very high
on the priority list.
--
- Harald Welte http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on August 27, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at August 27, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "osmo-remsim in practice" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on August 13, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at August 13, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "GSM-R and its differences to GSM" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Leaks simcom ?
Hi Bastien, On Mon, Aug 09, 2021 at 07:37:39AM +0200, Bastien wrote: > https://github.com/bbaranoff/simcom > https://pl4y.store > https://simcom.ee/documents thanks, those look just like the normal vendor documentation, similar to what you get either directly from the SIMcom website or via the distributor once you purchase their products. Nothing really surprising in there, at least AFAICT at first sight, only the normal manuals how you are supposed to do hardware integration or to talk to the modem via AT commands, etc. So, to summarize: Nothing really relevant within OsmocomBB or similar projects in kind, where the internal register-level documentation of the baseband/modem chipset would be relevant. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on July 23, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at July 23, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation on "high-level overview on IMS, VoLTE, VoWiFi" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on July 9, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at July 9, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 hands-on tutorial by miaoski: Setting up open5gs 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on June 11, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at June 11, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by keith: "Screen Sharing peek at TIC A.C. infrastructure in Oaxaca" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call TIC A.C. is an operator of Osmocom based community cellular networks in indigenous communities of the Mexican state of Oaxaca. Keith works with Rhizomatica and TIC A.C. and will give us some live insight into how they operate Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on May 28, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at May 28, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by fixeria: "Hacking binary protocols with Pycrate" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on May 14, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at May 14, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by laforge: "SS7 and SIGTRAN in 2G/3G networks" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will cover some classic circuit-switched SS7 basics as well as SIGTRAN (SS7 over IP) and how this is used as underlying transport for a variety of interfaces in the 2G (GSM) and 3G (UMTS) cellular networks even today. Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on April 23, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at April 23, 2021 at 20:00 CEST at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation by horiz0n: "YIG & YANG (Yet ANother yiG driver)" 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will briefly introduce the working principles of YIG (Yttrium Iron Garnet) microwave circuits, their applications and finally conclude with a presentation of a recently developed driver circuit. Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on April 9, 2021
Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at April 9, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: pySim-shell - the next generation of pySim 21:00 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: For more than a decade, pySim-prog has been the tool to configure/program SIM cards in research/lab/private cellular networks. Originally designed for very simplistic GSM-only SIM Cards, it was extended again and again to cover more use cases and parameters. There is a limit as to how far one can go with stuffing everything into command line arguments. In 2021, pySim-shell was created as the next generation tool. It features interactive navigation around the file system, editing capabilities, backup and restore of all [known] files, ... Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on March 26, 2021
Dear Osmocom community, It's my pleasure to announce the second OsmoDevCall at March 26, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This first meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: multi-TRX + frequency hopping in OsmoBTS 20:45 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will present the relatively recent introduction for the support of baseband frequency hopping in multi-TRX OsmoBTS. Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall" on March 12, 2021
Dear Osmocom community, It's my pleasure to announce the second OsmoDevCall at March 12, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This first meeting will have the following schedule: 20:00 meet + greet 20:15 presentation: 2020 Osmocom review 20:45 USSE: unstructured supplementary social event [*] 22:00 close of call Presentation Abstract: This talk will summarize the major developments within Osmocom during the year 2020. Focus will be on the Osmocom CNI projects, but will also cover developments in other projects Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) signature.asc Description: PGP signature
Osmocom Mailing List re-organization
Dear Osmocom community, This topic has been past due for way too many years by now: A re-organization of our major mailing lists. I would like to propose the following changes. Pleas let me know if you have any comments or feedback. I'm aware that renaming will mean people have to update their mail filter rules, but I think we're long past the point where the names of some of our lists started to confuse users. == open...@lists.osmocom.org == * openbsc doesn't exist anymore since OsmoNITB, which is also obsolete * does already cover anything "Osmocom CNI" related * Proposed new name: osmocom-...@lists.osmocom.org == osmocom-net-g...@lists.osmocom.org == This date back to when GPRS was a highly experimental add-on to our GSM code base. This list should simply be merged with openbsc@ as osmocom-...@lists.osmocom.org == simtr...@lists.osmocom.org == Historically was created to cover only the simtrace project. We should rename this to osmocom-simc...@lists.osmocom.org or something along those lines. I would like to suggest it covers * SIMtrace / SIMtrace2 hardware + firmware * pySim and related tools for working with SIM/USIM/UICC cards * any other information / discussion related to SIM/USIM/UICC cards, like OTA, ARA-M, ... == osmodev...@lists.osmocom.org == This has been a private list for people attending OsmoDevCon I would like to open up list membership to the general public, and ensure it also covers the new OsmoDevCall. We could then have discussions regarding feedback, topics, scheduling, etc. on that list. Maybe rename it to osmocom-eve...@lists.osmocom.org instead? To differentiate: osmocom-event-o...@lists.osmocom.org should remain a private list related to organizational / administrative topics of those involved with organizing future events. == next...@lists.osmocom.org == Should have been renamed to open...@lists.osmocom.org quite some time ago, I simply forgot about it. My apologies. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Announcement of "OsmoDevCall"
Dear Osmocom community, It's my pleasure to announce the first OsmoDevCall at February 26, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This first meeting will have the following schedule: 20:00 meet + greet 20:15 presentation about Cell Broadcast and OsmoCBC 20:45 USSE: unstructured supplementary social event [*] 22:00 close of call Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) signature.asc Description: PGP signature
Tonight: OsmocomBBs 11th anniversary party (online, of course)
Dear Osmocom community, today marks the 11th birthday of OsmocomBB, which had originally been announced on February 19, 2010 in the following mailing list post: https://lists.osmocom.org/pipermail/baseband-devel/2010-February/000142.html As we missed to properly celebrate the 10th anniversary, I'd like to use the off-by-one occasion to invite anyone interested to a spontaneous online birthday party tonight. As the original announcement was at 19:02:04 UTC, the online meeting today will also start at 19:02:04 UTC (that's roughly 8pm CET for those of us in the EU) at https://meet.sysmocom.de/OsmocomBB (password: Calypso) I know it's very shot notice, but I still thought it's a good idea, let's see whom of the past or current developers and users will be joining. There's no structure, presentation or anything. Just some USSE (Unstructured Supplementary Social Event). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Idea for 2021: Regular "OsmoDevCall"
Dear Osmocom community, On Thu, Dec 31, 2020 at 12:04:45PM +0100, Harald Welte wrote: > as the pandemic continues and physical meetings are out of the question > for the forseeable future, it would be a good idea to have a periodic > virtual online meeting of the interested Osmocom community. After some discussion in https://osmocom.org/issues/4928 and on IRC, I've now put together a wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Right now there's still a chance to influence the scheduling (current proposal is Fridays 8pm to 10pm CET). If you would want to participate but think this is a really bad time, please speak up now :) Once it is clear where we will host the call, I'd be announcing the first event, which could then be as early as Februray 26th. I'll keep you posted. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Idea for 2021: Regular "OsmoDevCall"
Dear Osmocom community, as the pandemic continues and physical meetings are out of the question for the forseeable future, it would be a good idea to have a periodic virtual online meeting of the interested Osmocom community. I was thinking of a format where we would serve two major purposes: 1) technical talks about osmocom relevant topics - ideally current/recent developments * can be pre-recorded to avoid any problems with technical setup, streaming, ... * should ideally have a Q+A session at their initial "airing" during one OsmoDevCall 2) unstructured solicited social event (USSE) * random chat in audio (optionally video) * not recorded, obviously The recording of the technical presentation should then be permanently made available (like the presentations of our prior OsmoCon / OsmoDevCon). Not every OsmoDevCall would neccessarily need the two parts, but I think it would be great if we can make that happen. We could also have e.g. a two-weekly schedule for the USSE and a monthly schedule for the technical presentation. We'd need somebody to volunteer to "manage" the "broadcast" side of this, preferably somebody with at least some prior exposure to online events (like the c3voc). I'm using https://osmocom.org/issues/4928 to collect a tentative list of topics. Feel free to add your ideas there, as well as any comment/ feedback you may have. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Osmocom C files syntax understanding
On Thu, Nov 19, 2020 at 09:27:39PM +0300, Mario Lucas wrote: > As it can be seen a structure «msgb» has as one of its components another > structure — «gsm_bts_trx» to be specific, the gsm_bts_trx is not a component of the msgb, but a _pointer_ to the gsm_bts_trx (i.e. a reference) may be present in the msgb. > But in whole Osmocom BB project files i could not find definition / > description of struct «gsm_bts_trx». libosmocore is primarily used by dozens of other osmocom projects, particularly every Osmocom CNI project. The gsm_bts_trx is likely used in osmo-bsc and osmo-bts. -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoDevCon / COVID-19
Dear fellow Osmocom developers,
as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year. At the time, we discussed to re-visit the situation
in October 2020.
While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.
Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.
I'm not 100% in favour and not 100% against. Hence, I would like to get
your input. Should we
a) try to get an event organized on-site in Berlin? We'd have to move
to a larger venue than IN-Berlin with proper ventilation and sufficient
space so we can keep physical distance, but I think that's
manageable for sysmocom as organizer.
b) simply postpone to 2021? I'm convinced the situation will not change
significantly (in a positive way) until late April 2021, so it's not
really a "solution" as it will likely mean we have to think of late
2021 or 2022.
c) plan some kind of online conference? To be honest, I think this
model works fine for events where a single speaker wants to give
lectures to hundreds or thousands of participants. But OsmoDevCon
is much more interactive. We could record or live-stream some talks
or screencasts from home, sure. But that only captures one part of
the event. We could also try to set a date for a collaborative
mumble, or the like - for the "hallway track".
What are your thoughts? Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on open...@lists.osmocom.org.
Regards,
Harald
--
- Harald Welte http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Osmocom scheduled outage on *2020-07-21 7.30am CEST*
Dear Osmocom community, the migration to the new server has completed today. All services are up and running. There will be another scheduled outage on Tuesday, July 21 at 7.30am CEST This second outage is to migrate the old server IP addresses to the new server, which appears to involve physical relocation between racks. Happy hacking! -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Osmocom scheduled outage on *2020-07-19 9am CEST*
There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB
On Tue, Mar 03, 2020 at 12:45:14AM +0300, Антон Левченко wrote: > Hello! During build OsmocomBB I have problem. When I do "make", I get > errors: *** No rule to make target `geo.c', needed by `geo.o'. Stop. It seems like you have accidentially deleted the file src/host/layer23/src/misc/geo.c from your source tree? What does 'git status' tell you? -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Osmocom GTM-900B carrier board
Hi all! It is quite some time since it was brought to our attention that there's an old Huawei module that also uses the Ti Calypso chipset and hence can be used with OsmocomBB: The GTM-900B. It's just a modem module with a FPC connector, so no easy to use interfaces for any of the related signals, no SIM holder, etc. At sysmocom we've finally found some time to do a carrier board design for this, which will expose all the relevant signals (audio, UARTs, power, reset, ...). Martin (Cc) is working on it right now. The discussion regarding this breakout board can be followed at https://osmocom.org/issues/4030 If you have any input, please provide it now, as we are trying to complete this design by the end of the week so we can order prottoypes. The actual design files (EAGLE) including a PDF export of the schematics can be found in the osmo-small-hardware.git repository. Thanks for your input. Once the prototype is validated, we plan to make the boards (bundled with GTM900B) available in the sysmocom webshop. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoDevCon 2020 registration
Dear fellow Osmocom developers, I would like to invite all developers and contributors to Osmocom [sub]projects to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin). For details known so far, please check http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2020. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) signature.asc Description: PGP signature
Re: Osmocom Village at CCC Camp 2019
Hi Neels, On Mon, Jul 29, 2019 at 05:12:11PM +0200, Neels Hofmeyr wrote: > I am noting possible duplication in effort preparing the camp as well as > digital infrastructure. Apparently bibor and lynxis aim to manage wiki etc on > code.fe80.eu and the event-orga ML, and Osmocom to be part of the Singularity > City. In contrast, this Osmocom Village mail seems to suggest a separate > village and wiki+ML. I also at some point noted separate efforts made by > different people for setting up a large Osmocom tent, IIUC. I think the "problem" here is that we have two disjunct communities: 1) The wider "Osmocom and friends" community, consisting of people related to Osmocom projects unrelated to GSM/cellular, but even reaching into the gnuradio crowd, who had historically also been sharing the Osmocom village. This is about bringing together people working on various SDR / communications related topics for "hanging out, chatting, ...". As I wrote before, people have reached out to me about this for months. 2) The "post LaF0rge" team operating the 2G/3G network at CCC events. I see that as a rather "production oriented" team which has to work closely with the POC, etc. and which shouldn't be bothered/distracted by people who are not involved in that. > I'm not sure how to consolidate, but I get the strong feeling that bibor, > lynxis and laforge should talk about the camp preparations to avoid > "aneinander > vorbeireden", confusion and redundant efforts ... ? I'm always open to discuss, but after months of public posts on this ando ther mailing lists, I'm not sure what there is to add. In short: * both villages are now part of Singularity City * Osmocom Village has no separate tent/infrastructure but people will hang out at the singularity city hackcenter. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Osmocom Village at CCC Camp 2019
Dear all,
I've been asked by a number of pepole about a possible Osmocom village at the
CCC Camp 2019. I personally didn't really have any plans, but given related
e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
see
https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
I also created a wiki page (as nobody else did, despite earlier discussion on
IRC,
SCNR) for coordinating related efforts at
https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
One of the bigger questions is about having a tent as well as some
tables/benches
to sit on and work. The Camp orga team nas been negotiating rates with a tent
rental company, but to be honest I'm rather surprised by the extremely steep
pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not
sure we want to raise that amount of money? Even if we'd be 10 people sharing
it, its still 82.50 EUR per person. And that excludes any tables/chairs.
I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
Please note there also is some kind of fragmentation / overlap with the
team planning to run the GSM/3G networks at the camp, see Lynxis'
related post at
https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/000362.html
It's questionable whether it makes sense to have tow distinct
'villages', but given that e.g. I don't know anyone of that singularity
city, I'm not sure if we'd either be welcome there, nor whether we'd
want to associate us with them? Also, while the GSM network operation
for sure has good reasons to mingle with the POC and whatever facilities
they have, I'm not sure if the wider Osmocom community attendees
unrelated to the GSM network operation wouldn't just be a
disturbance/nuisance.
In the end, to be honest, I personally do not feel I have the time and
mental capacity to take on any additional tasks in terms of organizing
anything. I just created the entry in c3assemblies as I was asked to,
and I similarly created the related mailing list and wiki page.
So please, anyone interested in making an Osmocom village happen one way
or another, step up [and continue this discussion on the
camp2019-vill...@lists.osmocom.org mailing list, without crossposting
everywhere else :)
Regards,
Harald
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Ticket sale is over. There are no more tickets available. There will be no
ticket sale on site. That means
you should know how many will join your village. In the next days we start
planning the placing of the
assemblies, we need your help.
Please update your village registration at [3] https://signup.c3assemblies.de/
with the number of people
who will join, extra space you require, power requirements, and such. Please
write all information to be
considered in the village registration form.
There have been some frequently asked questions in the last weeks. So we want
to address some topics here:
Tents/Tables/Benches/Construction Wood:
Prebuilt tents, tables, benches and wood can be borrowed or bought via the
presale system: [4]
https://tickets.events.ccc.de/camp2019hw/. For now there are only tents because
we need to order them
soon. The rest will follow and can be bought with the same voucher. You will
recieve a voucher with this
email (see below). The earlier you order your stuff, the more likely we can
provide what you want.
Especially tents might be in short supply. Please remember bringing cash for
the mandatory deposit of €
100,- for renting tables and benches.
Water:
We want to remind you, if you bring cooking equipment, there will be no direct
fresh water and waste water
supply for your kitchen. We will have some central places with fresh water
supply and where you can wash
your kitchen utensiles and dishes.
Power:
Power will be generated from diesel with power generators. All engergy you'll
use will have to be
generated. Think about our environment and use as little power as possible. For
that reason, there is no
possibility to fulfill high power demands for pizza ovens, saunas and alike. If
you need cooling for your
food supplies, please think about your refrigeration requirements. Less is
more. And please bring enough
outdoor and rain proof extension cables to connect your tents and equipment.
Fire:
Open wood or coal fire is not allowed at any time. That applies for anything
that needs heat for kitchen
usage. If you need heat, please bring your own safe gas-based camping heaters.
Waste:
Of course there will be containers for waste, paper and glass on the camp site.
But the camp tries to be
as sustainable and ecological as possible. So please consider bringing reusable
dishes
GTM-900B for OsmocomBB developers
Hi all! sysmocom has obtained a first batch of 10 GTM-900B with some FPC-to-2.54mm-breakout adapters from songbosi. They have just arrived yesterday in Berlin. I'm happy to make them available for free to [known/existing] Osmocom develoepers/contributors. Let me know if you're interestd and we'll send you an envenlope, likely mid next week due to the upcoming extended whitsunday weekend. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: hand-over in L1CTL / trxcon
Hi Vadim, On Fri, May 31, 2019 at 09:55:22PM +0700, Vadim Yanitskiy wrote: > > Looking at layer23, it seems we have DM_REL_REQ, then RESET, > > then a new DM_EST_REQ during assignment. > > Right. I am now wondering, wouldn't this intermediate > L1CTL_RESET_REQ cause an additional delay for handover? I would assume the reset of the data structures is quite fast compared to anything on the GSM radio interface? Not sure if it would matter? > >> So there is no warranty that the new dedicated channel would contain > >> RACH slots, right? That's another limitation of trxcon: it can send > >> RACH bursts on RACH slots only, and only on TS0. > > Fortunately, I found a work around, please see: > > https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/ Thanks, this has meanwhile ben merged. > I've just confirmed that trxcon properly sends Access Bursts > on any (activated by L1CTL_DM_EST_REQ) time-slot, please see: > > https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14291/ Which has also been merged, and is executing + passing for seveal consecutive days, see https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_results_analyzer/ Thanks! > In short, it doesn't detect handover RACH. > > The problem seems to be here: > > https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n986 > > An Access Burst is merely ignored if a logical channel is not active. The logical channel must be previously activated by the BSC using RSL CHAn ACT with type == handover. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
L1CTL extension (was Re: hand-over in L1CTL / trxcon)
Hi Vadim and others,
given how long L1CTL has been around, and how many programs implement
it by now, I really would like to ensure backwards compatibility without
introducing weird breakage all over the place.
The good news: I think it's possible to extend L1CTL in a
backwards-compatible way, and I started with a related implementation.
Some of my raw notes below:
---
Extension of L1CTL in a compatible way
* enhance l1ctl_reset with version and feature bitmap
** used by L1CTL_RESET_CONF, possibly also REQ, IND
** old implementation ignores trailer
** new implementation recognizes new format due to longer message (and enables
use of new features)
* new DM_EST_2_REQ
** sent by L23 only if feature-bit was set in RSEET_CONF
** contains additional fields
*** L1 SAPI bitmask
*** sync_source member to select own cell or neighbor cell sync info
* new DM_EST_2_CONF
** response to _REQ (which is currently missing from DM_EST_REQ)
* extend l1ctl_neigh_pm_ind with new fields at end
** L23 can use size to determine if new fields exist or not
* new DM_MODIFY_REQ
** sent by L23 to change L1 SAPI bitmask
* new DM_MODIFY_CONF to confirm it
/* bit definitions for individual features communicated in RESET_CONF */
enum l1ctl_feature {
L1CTL_FT_DM_EST2_MODIFY, /* DM_EST_2 and DM_MODIFY procedures */
L1CTL_FT_RACH_DM, /* RACH can be sent in dedicated mode */
L1CTL_FT_EXT_RACH_REQ, /* Extended RACH (11bit) support */
L1CTL_FT_SPKR_MIC, /* Hardware Speaker + Microphone supported */
L1CTL_FT_TRAFFIC_IND,
L1CTL_FT_BURST_IND,
L1CTL_FT_TBF, /* support for TBF_CFG and DATA_TBF procedures */
L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */
L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */
L1CTL_FT_BAND_850,
L1CTL_FT_BAND_900,
L1CTL_FT_BAND_1800,
L1CTL_FT_BAND_1900,
L1CTL_FT_CIPH_A51,
L1CTL_FT_CIPH_A52,
L1CTL_FT_CIPH_A53,
};
---
I won't go "full steam ahead" on this, but will try to get it
implemented within the next week or so.
Regards,
Harald
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: 回复： Perfect module (D751749ZHH)
Hi! thanks for sharing the pictures. Can you please submit your patches / changes to OsmocomBB, so we can officially support this module from OsmcoomBB? Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: hand-over in L1CTL / trxcon
ing a completely new dedicated L1 channel. The higher-layer state (L3+) is retained, but L1 and L2 are completely new. So I don't think this is just a frequency + TDMA change. > - Alternatively, we can introduce L1CTL_DM_HANDOVER_REQ that >would contain both FDMA and TDMA parameters. I would think that's too specific. I would say we release the old channel and establish a new one. And if the new one fails to establish, we re-establish the old one using the freq + TDMA sync information we've kept around for the old cell. > - Let's introduce a new L1CTL message for (de)activating TDMA >timeslots on the current channel, I would consider this part of DM_EST_REQ + DM_REL_REQ - for both the Assignment and the Handover case. The only difference is whether we stay with freq+TDMA sync on the current cell, or on a new cell. > and (de)activating its logical channels. bitmask of L1 SAPI in DM_EST_REQ and new DM_MOD_REQ. > - We need to implement the ability to schedule tasks at the given >TDMA frame number in trxcon, so it would be possible to change >the FDMA and TDMA parameters, and send Access Bursts >on non-RACH slots. Not sure how much of that we really need beyond ability to send RACH on normal traffic channels... Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OSMO-nitb problem
Dear Bilguun,
plase note OsmoNITB is obsolete and no longer maintained for quite some time
now.
We strongly encourage you to use the new "split" stack with separate BSC, MSC,
HLR, ...
Please follow instructions at
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box
On Tue, May 28, 2019 at 02:47:38PM +0800, Bilguun Tugs wrote:
> Error occurred during reading the below line:
> timer t3103 0
you are using a configuration file from a program version that doesn't match
the version you are using. I'm a bit puzzled about this, as the timer-related
command was added in Nvoember 2009 in commit
23975e718fd456ff8be7effbb915903f1bc173be.
Regards,
Harald
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: Perfect module (D751749ZHH)
Hi Songbosi,
On Tue, May 28, 2019 at 06:25:20PM +0800, songbosi wrote:
> I have disassembled many old GPRS modules , at last I found this
> module is perfect(D751749ZHH). Now I have 500 pcs left
Can you clarify which particular "module" you are referring to? Where
can the interested OsmocomBB developer/user community obtain them from?
> This module have TCK/TMS/TDO/TDI ，I make a custom OsmocomBB firmware
> , only need modify some IO control for RF switch, there are some
> picture to share with you.
As Osmocom is a collaborative open source development project, we would
appreciate your patches and other contributions to the code at least as
much as pictures of what you are doing :)
Regards,
Harald
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hand-over in L1CTL / trxcon
Hi Vadim, I'm currently facing the problem of testing hand-over related channel-activation in OsmoBTS. Three are various rules about how this has to be done, and a closer look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that right at all. I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL to control a (virtual or real) L1 for the MS side of testing the BTS. To break this down to low-level requirements in terms of MS capabilities: * switch to a different ARFCN * switch to a speciifed timeslot * change the synchroniztaion (in terms of where we currently are in the TDMA multiplex) to a given neighbor cell. The MS will have performed neighbor measurements before, and as part of that will hav received FCCH + SCH and hence know the timing both in terms of carrier freq as well as TDMA position [none of this is relevant for a fake_trx + trxcon setup] * ability to enable only the receiver for the main channel (SDCCH/FACCH), but suppress any reception (or passing up of received) SACCH. * ability to transmit RACH burst[s] in uplink on that new dedicated channel * ability to later on enable full Rx/Tx of all logical channels on that dedicated channel I've looked at the jolly/handover branch from 2013, and rebased that on top of current master, the result can be seen in laforge/jolly_handover_rebase Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags to DM_EST_REQ to * disable uplink transmission * use the sync information of a neighbor cell I would like to get at least that change to L1CTL merged to master, and while doing that, update all implementations of L1CTL at the same time. It may make sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while at it, which is required for neighbor channel measurements + reporting. We should also use that opportunity to introduce some kind of versioning support to L1CTL, to ensure future extensions of the protocol can be made in a way where incompatibility can at least be detected at runtime. Now the next question is how to this will impact trxcon/fake_trx. AFAICT, there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ would fail if there was already and established channel before. Is that correct? If so, what is the suggested/recommended way to get trxcon to support at least the minimum of what's required for handover in a virtual environment? Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Free board offer to OBB developer with a CMU200
Hi Mychaela,
On Sat, Apr 06, 2019 at 09:39:25PM -0800, Mychaela Falconia wrote:
> Craig wrote:
> > I have been working with osmocom-bb since around 2010,
>
> So you have been at it for at least 3 y longer than I have, and you
> still haven't offered much to show for it..
Once again, there is no competition here. Not everybody has the same
time and resources, level of technicality, etc.. Not everyone has the
same goal. Maybe some people just want to have a fun hobby learning a
bit more about GSM, reverse engineering, etc. ?
> > dabbling in porting layer1 to nutt-x
>
> What is the deal with that NuttX thing? What makes all of you think
> that it is such a good idea? Just because someone said so?
That Someone would likely have been me.
> None of the mainstream, commercially successful GSM modem firmwares from any
> reputable vendor use NuttX, they all use Nucleus, ThreadX or L4
> instead.
So what? None of the mainstream operators are using network-side Osmocom
components, but still they generally work, and some smaller operators have
been running them very successfully so ;)
None of the mainstream IT companies were using Linux in the mid-1990ies,
still it was quite capable back then.
> > and starting 2-3 years ago working more earnestly on
> > understanding layer1 and porting it to fernvale.
>
> 2-3 y ago is the same time when I went from running FreeCalypso purely
> as a software project to producing my current FCDEV3B hardware. So far
> my approach has worked out a lot better: FCDEV3B is now a practically
> usable commercial-quality GSM+GPRS modem that is fully fit for
> operation on live GSM networks, which cannot be said for Fernvale.
Did it occur to you that Fernvale had completely different goals?
Also, how long do you think that your "commercial quality" modem will
continue to be available, given the ancient, end-of-life components it
requires?
MTK still produces newer baseband chips with GSM/GPRS support, and from all we
know they didn't significantly change that 2G part in ages. Why would they? It
just lives next to their 3G/4G modem parts, probably copy+pasted from the older
designs.
> In other words, operating those MTK chips as general-purpose
> microprocessors without any cellular radio functionality, right? What
> you are doing here would indeed be a necessary foundational step *if*
> you had some *realistic* plan for how you are going to bring up
> cellular radio functionality, but it does not sound like you have any
> such realistic plan.
Please stop that negative attitude. Nobody needs any realistic plan if they
want to play/hack around.
> This is the part that shows most clearly how out of touch you are with
> reality when it comes to your idea of OBB on MTK.
Maybe it's you who is out of touch with Craigs reality? I think Craig
is quite realistic when it comes to his ability to create a "production
ready GSM/GPRS modem". But did he state anywhere that this is what
he's aiming for?
> I am part-time too, I am NOT independently wealthy to where I could
> work on FreeCalypso full-time. Yet having a limited time budget is
> not an excuse for making poor judgments as to what is realistically
> doable and what isn't, deluding yourself and misleading others into a
> land of false hopes.
Please respectfully leave it up to others to make whatever judgements
they want on how they spend their spare time. We're not telling you
how to spend yours either.
Having said this, please feel free to share your points of view in a
neutral way - but don't be judgemental and/or attack other people just
because they are doing something that's not according to your taste,
or which you think is inferior.
To put it in the words of Rosa Luxemburg[1]:
"Freedom is always the freedom of dissenters."
Regards,
Harald
[1] https://en.wikiquote.org/wiki/Rosa_Luxemburg
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Tone on this mailing list (Re: Free board offer to OBB developer with a CMU200)
Dear Mychaela,
I'm a bit upset by the tone of your message. This mailing list is for
discussing open source mobile communications (specifically, in this case,
on the phone/UE side). Anyone is welcome to share their views, but there
is no competition here.
I'm very impressed by your achievements with FreeCalypso, and I'm happy
you are participating our discussions here and staying in touch with
Osmocom, as well as helping it along [despite of what I feel is a
somewhat difficult relationship for you]. However, having achieved a lot in
this field yourself doesn't give you the right to intimidate or bully
other members on this mailing list.
So I would kindly request you to show respect to every hacker who is
working in this field, no matter where they are with their project,
and no matter what their "track record of achievements" may look like
so far.
Particularly we, the people with lots of experience and achievement in this
field, need to nurture and encourage others, rather than intimidate them.
I see the following part of your message as problematic:
On Sat, Apr 06, 2019 at 01:14:55PM -0800, Mychaela Falconia wrote:
> Now please present your story (meaning Craig) - how long have you been
> actively working toward your respective goal? What do you have to
> show so far?
> [...]
> Just trying to see if you have anything real and tangible to show for
> your idea of OBB on MTK, that's all...
Nobody is accountable to you and has to provide you with a record of
how long they have worked on something or what they have achieved.
Everyone is welcome and encouraged to share what they're doing, but
that's completely voluntary and up to them to disclose.
No volunteer working on a FOSS project in their spare time is required
to achieve anything [beyond what they have as goals themselves].
Craig has been determined for many years and has been working on this on
and off, as I understand. The mere fact that given such a huge and
difficult task he hasn't given up yet is a very positive surprise :)
So please let's try to be more positive and encouraging, and help others
trying to venture into the area of reverse engineering cellular baseband
processors. We need more of them, not less :)
Thanks for your kind understanding. I hope we can avoid any further
discussion on this topic and return to investing all our time into
improving open/free cellular technology.
Best Regards,
Harald
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: Free board offer to OBB developer with a CMU200
Hi Felix,
thanks a lot for your generous offer. I'm very happy to see this, but
I have very limited hope that at this point somebody would still show
such substantial interest in testing compliance of OsmocomBB :/
But for sure, let's hope my pessimism is overrated and someody would
invest time into this.
On Mon, Apr 01, 2019 at 05:29:58PM +0200, Felix Domke wrote:
> If someone is interested in this, please contact me off-list. Bonus
> points if you're interested in setting this up in an automated fashion
> that lets us test OsmocomBB builds automatically and generate a report
> for each commit.
I'd be happy to put some sysmocom resources behind this, if it helps.
I'm assuming that if somebody creates the "manual" test setup and
works on fixing some of the fall-out, we'd contribute some development
time on automatizing this setup, and also hosting/maintaining it, doing jenkins
integration, ...
In addition, irrespective of the above, sysmocom is happy to provide
whatever calypso phones, cables, adapters, attenuators, duplexers,
USB-UART-Cables, etc. for completing the physical setup. This offer is
valid for anyone who'd receive Felix' equipment. Let me know what you'd
need/want and I'll try to make sure you get it.
Regards,
Harald
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: Google Summer of Code 2019
Hi Vadim, On Mon, Jan 14, 2019 at 10:42:05AM +0700, Vadim Yanitskiy wrote: > starting from 16th of January (until 7th of February) we can apply > Google Summer of Code as an Open source mentor organization. Thanks. It's something that I've been pondering several times in the past, too. I know Holger did it once for Osmocom in the past, AFAIR, and in netfilter (where I was involved before) we also participated in GSoC. The results were - as any results from new developers - mixed. But I think it's a good opportunity to get new people involved in the project. > Personally, I think it's a great opportunity to move some of our > projects forward. I would like to know your opinions about this > idea, should we participate? I would be happy to be a mentor. I think it's a good idea and I'd support it. I just know that given the many projects I'm already way too late with and overloaded, I will not be able to personally mentor a GSoC student. So I'm happy to help with formailtiies, etc. - but that's about it, sorry. -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: How osmocom-bb(mobile app) display non-english character SMS
Hi dechao, On Mon, Jan 07, 2019 at 08:11:22AM +0800, dechaoforever wrote: > Last weekend I compiled osmocom-bb and now I can send English SMS from one > peer to another by using its app 'mobile'. But how to make it possible if I > want to send SMS including non-English character, like below. You will have to implement support for UCS-2 character set based SMS to OsmocomBB, I think nobody has implemented this so far. We are very much looking forward to receiving and merging any related patches! Thanks, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoDevCon 2019 registration
Dear fellow Osmocom developers, I'm a bit surprised to notice that not more people have signed up for OsmoDevCon 2019. I guess it was mostly an oversight when the date was originally announced, and not a lack of interest? ;) All details about the event are available at the related wiki page at: https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2019. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Questions regarding maintaining synchronization of a mobile station
Hi Piotr, On Fri, Sep 21, 2018 at 10:07:20AM +0200, Piotr Krysik wrote: > Gr-gsm's receiver currently relies on having SCH channel to keep > synchronization. are you referring to carrier clock (oscillator) synchronization, or TDMA multiframe synchronization? > To do this it would be great to know how normal mobile phones maintain > synchronization, something I don't know currently. Especially: > 1. How often mobile station (MS) checks if the synchronization is kept? > 2. What is usually used to check if synchronization is kept, especially > when a MS is on a traffic channel? > 3. How MS regains synchronization? Does it always do full FCCH+SCH scan? For tracking the clock of the currently serving BTS, you have the coarse search window of +/- 1kHz clock difference until you've been to FACCH+SCH sync. From that point on, the clock drift between sender and receiver is tracked by relying on the TCH only. I think e.g. the calypso had something like +/- 50Hz tracking capability while on a dedicated channel, meaning if there's more clock difference, it would no longer lock onto the signal and just receive junk, leading to L2 closing the channel. In terms of synchronization to the TMDA frame of the other cells: This is part of the neighbor cell measurement process, and I'm quite sure it's specified quite tightly in the relevant specs. IIRC, the MS must at least monitor up to 12 meighbors of which the 6 best are to be reported during the measurement report. For tracking the neighbors during active use of TCH, the MS uses the IDLE frames in the 26-multiframe. It keeps "sync state" for each of the neighbors, including * carrier clock / oscillator recovered from FACCH on that neighbor * BSIC + frame number on that neighbor If the BSIC ever changes, the MS knows that the neighbor has changed (different neighbor on same ARFCN) and all higher-layer state must be invalidated. I'm quite sure pretty much all of this should be in the jolly/handover branch of osmocom-bb.git Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoCon 2018 draft schedule announced
Dear Osmocom community,
the first schedule of the 2018 incarnation of OsmoCon 2018 has been announced,
see http://osmocom.org/news/99 for the announcment and
https://pretalx.sysmocom.de/osmocon2018/schedule/ for the actual schedule.
At OsmoCon, we are not targetting developers, but more the wider community
and Osmocom users. It would be great to meet many of you and hear more
about your relation to Osmocom.
Tickets are available from https://pretix.sysmocom.de/sysmocom/osmocon2018/,
and until August 31st the early bird discount still applies.
For those with a community / "just for fun" background and no employer
that would cover the ticket, we have a number of subsidized community discount
vouchers available. See the OsmoCon 2018 wiki page at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
for more information.
Looking forward to meeting as many of you as possible in roughly two
months from now,
Harald Welte
--
- Harald Weltehttp://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: Proper measurement reporting
Hi Vadim, following up on this as I was browsing through the list of open issues and ended up on OS#2988 and https://gerrit.osmocom.org/#/c/osmocom-bb/+/7470/ On Fri, Mar 23, 2018 at 08:20:22PM +0700, Vadim Yanitskiy wrote: > In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH > procedures", Measurement Report messages are sent at each possible > occasion when nothing else has to be sent. In other words, a dummy > LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here. this part is clear so far. > The Calypso PHY (i.e. the firmware) is sending self-composed > Measurement Reports if there is nothing in transmit queue: > > [...] > > I am not sure if this is the correct way. Why? > > - The Measurement Reports coming from the higher > layers may contain additional information, such > as the neighbour measurements. > > - The higher layers may spoof indicated TA value, > while this code uses the actual one. > > - Measurement Reporting is already implemented > in the higher layers, so this duplicates... I agree. > My current ideas are: > > 1) Create a separate L1CTL message, that would be > used to carry Measurement Reports. This way > we wouldn't need to extract them from the > L1CTL_DATA_REQ messages manually. As sylvain already stated, there doesn't seem to be a need for yet another extra primitive. For the MS side, it is a DATA_REQ on the uplink SACCH SAPI. > 2) Keep a last Measurement Report somewhere, and > transmit it until a new one is arrived from > the higher layers. That makes sense. However, that cached last measurement report should have some kind of age attached. There's no point in tranmitting neighbor measurements that are 5 minutes old, particularly not for a mobile user. > Probably, some parts of the Measurement Reporting implementation > should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY. > This way each Measurement Report would always contain the actual > measurement results at the moment of transmission... Measurement reports are sent every SACCH multiframe (102 or 104 frames), i.e. about every 500ms. Also, the end of the measurement period is defined independently from the time at which a measurement report is being sent. There are, AFAICT, about 12 frames between the end of the measurement period and the start of the transmission of the measurement report. That's about 55ms of time. I think 55ms might be indeed a bit tight to account for Caylpso->UART->osmocon->mobile->osmocon->UART->Calypso. At 115200 bps, there's onyly 633 characters in that period. Hoewver, I think we shouldn't focus too much on the constraints of the slow serial link of calypso phones here. In the worst case, our measurement reports will be 480ms old, so be it. -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
OsmoCon 2018 CfP / submit your topic[s] *now* !
Dear Osmocom community, one of the main difficulty with OsmoCon 2017 last year was that nobody submitted talks / discussions within the deadline, early enough to allow for proper planning. This lead to the situation where the sysmocom team had to come up with a schedule/agenda on their own. Later on *much after the CfP deadline*, people then squeezed in talks, making the overall schedule too full. It is up to you to avoid this situation again in 2018 by submitting your talk *RIGHT NOW*. We will be very strict regarding late submissions. So if you would like to shape the Agenda of OsmoCon 2018, this is your chance. Please use it. We will have to create a schedule soon, as [almost] nobody will register to a conference unless the schedule is known. If there's not sufficient contribution in terms of CfP response from the wider community, don't complain later that 90% of the talks are from sysmocom team members and only about the Cellular Network Infrastructure topics. You have been warned. Please make your CfP submission in time at https://pretalx.sysmocom.de/osmocon2018/cfp before the CfP deadline on *2018-05-30 23:59 (Europe/Berlin)* Thanks for your kind attention. Looking forward to meet with the community at OsmoCon 2018 in October. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: osmocom-bb installation help
Hi Nikos, On Sat, May 12, 2018 at 04:09:47AM +0300, Nikos Balkanas wrote: > According to the src/README.building file, I should get the arm toolchain > from gnuarm.com > This should be updated, gnuarm.com doesn't have any downloads any more. > Instead I installed gcc-arm-linux-gnueabi from ubuntu reps Won't work, sorry. You need the specific toolchain, see https://osmocom.org/projects/baseband/wiki/GnuArmToolchain also note https://osmocom.org/issues/1916 > 1) normal gcc seems to support x-compiling for arm CPUs. Why not use that? if it was that simple, we wouldn't have to rely on one specific old toolchain. The OsmocomBB code was simply developed 8 years ago, and while lots of people ar very enthusiastic about using it, not one such user has been bothering over the coures of 8 years to invest the time to port the code to more modern toolchains :/ The biggest knwon problem is about the fact that GNU binutils changed their features/syntax for the linkerscripts, see https://osmocom.org/issues/1917 > 2) Your stock Makefile tests for CROSS_HOST against arm-elf-gcc. This > should be updated to test also against arm-linux-gnueabi-gcc from > gcc-arm-linux-gnueabi package No, it should not be updated, as it won't match a toolchain/compiler that will produce a working binary. > 3) configure warnings: > configure: WARNING: unrecognized options: --disable-tests, --disable-tests. > Should be disabled if not supported any more > checking for arm-linux-gnueabi-mt... no > checking for mt... mt > configure: WARNING: using cross tools not prefixed with host triplet > Is there a problem to use the OS mt? It would be helpful if you could explain which "configure" are you talking about? There are a total of _7_ configure scripts in the osmocom-bb source tree. > 4) configure asks for libosmovty >= 0.10.0. libosmovty is part of > libosmocore. Latest libosmocore master provides libosmovty 0.9.0.16-abc4:( Again, *which* configure? Also, are you talking about a requirement for libosmcoore on the host or on the target? The libosmocore included in the osmocom-bb.git repository is *ONLY FOR CROSS-COMPILATION TO THE TARGET* as is stated very clearly in README.building. Also, the master makefile will not do that. As written already earlier, libosmocore.git contains a version >= 0.10.0 for more than six months. Please make sure you understand your build process and ensure you are not using outdated source code to build, or building against outdated installs of libosmocore that may still be somewhere installed in your search paths. btw: the OpenSUSE package feeds by Martin Hauke contain builds of a suitable cross-compiler as well as pre-compiled omsocom-bb firmware: https://build.opensuse.org/project/show/home:mnhauke:osmocom:nightly This is not available in the official osmocom Debian builds. We're always happy to merge related contributions, though. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: GSM 04.08 L2 pseudo length in ACCH System Information messages
Hi Vadim, On Thu, Dec 14, 2017 at 01:57:11AM +0700, Vadim Yanitskiy wrote: > I looked at the specifications again, and found out that initially I > refered an outdated 5.3.0 version, which was the first link in Google: > > http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p.pdf > > while the latest one is 7.21.0: > > http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100940v072100p.pdf > > So, I compared the 9.1.37-40 sections of both versions, and bingo! > In the higher version ACCH System Information messages do have the > 'L2 Pseudo Length' (10.5.2.19) field. I think you have to review the matching 04.06 / 44.006 together with it. My suspicion is that earlier, 04.06 might not have specified the B4 frame format for downlink SACCH but simply used a normal B frame format (with length octet at L2). Or specified that the B4 frame format includes the length octet. It looks like what used to be a regular UI frame length octet in L2 has at some point been moved into L3 in order to achieve phase1 compatibility by having a length octet that's shorter than the payload length. Old phones will then only look at the "length" number of bytes, where newer phones will look at the full message. If they kept the length octet in L2, L2 would have automatically calculated the length to the total length of the message, including all phase2 extensions. So I guess that's why they came up with that ugly hack of defining L2 as not having a length (only addr + ctrl on downlink sacch) and the L3 including a length octet. >From the wire format point of view, you always have * two octets L1 header (power control, TA loop) * one octet ADDR * one octet CTRL * one octet [either L2 length or L2 pseudo length] * the actual L3 payloda The question is just whether you group ADDR+CTRL+LEN into L2 or you put LEN+L3 into L3. If my line of thinking is correct (see https://osmocom.org/issues/3059) we need to make sure * the L2 pseudo-length is included in all SACCH downlink L3 info on RSL, see https://gerrit.osmocom.org/#/c/7220/ * fix the wireshark dissector for SACCH, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105 * fix the wireshark RSL dissector for RSL (SACCH FILL, SACCH INFO MODIFY, CHAN ACT) Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
port numbers in FakeTRX / trxcon
Hi Vadim, while playing with fake_trx and trxcon I was wondering about the port numbers you used. I think it's not the best idea to re-use the same port numbers / port number range on the MS side which are used on the network side. Is there any requirement to do so? why not simply shift the entire base port (5700) on the client side to something else like 6700? (Side note: The entrire TRX protocol using so many non-standard/non-IANA port numbers, not containing any version numbers for extensions, etc. is a mess, but that's for a separate discussion altogether. Would love to re-do this from scratch at some point) Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: sciphone dream g2 mtk 6235 status? ;)
Hi Craig, On Thu, Feb 15, 2018 at 10:48:50PM -0600, Craig Comstock wrote: > The craig_comstock account works fine. I added a bunch of MTK related > bits to the wiki. Hopefully it's not too much or "out of style" or > "vaporware". I tried to limit myself to stating facts that I am > confident about. I did a quick review and think everything is fine with the way you added information. > I should probably try and fiddle some more with my simple-serial.py > script to provide basic chip-id POC for various devices. I can use the > osmocom-bb wiki as a place to share notes on addresses I find and > such. great. > I ran into a snag trying to support a blink firmware on both sciphone > dream g2 and fernvale well, I think the really interesting part of those devices is their cellular/RF side, not the LEDs :P But well it's of course your time and your decision how to spend it :) > Thanks and let me know where to RTFM about adding things to the wiki > properly if there is a doc/page about that. I don't think there are any manuals about this, aside from the redmine wiki syntax reference. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Approach to system testing for Osmocom stack
Hi Holger, thanks for your status update. Looking forward to the related code. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: GAPK merge request
Hi Vadim, just some feedback "from the side": On Sun, Jan 14, 2018 at 02:19:46AM +0600, Vadim Yanitskiy wrote: > http://git.osmocom.org/gapk/log/?h=fixeria/lib I've done some casual review and it looks great to me. There are some minor issues: * I would suggest internal symbols (those not with osmo_gapk_ prefix, like gapk_log_subsys, LOGPAPK, ...) use an internal header file which is not installed in the system. The header files installed during 'make install' should only describe the external API of the library * the source/sink/coec category name stringification at http://git.osmocom.org/gapk/commit/?h=fixeria/lib=459791c488c6b66a5cd0d7cff9392a7a0b8ca733 should not define those strings in every file, but have a value_string or at least some #defines or the like. This is just my point of view, detailed review of course depends on Sylvain. I suggest you simply rebase your chain of commits on current master and push it into gerrit. That's what we have it for, and as indicated in http://lists.osmocom.org/pipermail/openbsc/2017-December/011523.html gapk has been introduced to gerrit. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Approach to system testing for Osmocom stack
Hi Holger, On Wed, Jan 10, 2018 at 10:52:59PM +, Holger Freyther wrote: > okay. That reduces some degrees of the freedom. Where to put it? Into the > OsmocomBB sources? Osmo GSM tester even if it might not share much code? If you reuse osmo-gsm-tester code for templates or the like, then it should probably go there. If not, OsmocomBB seems like the more logical place. Would be great if in that case it is some kind of python library/module and a small 'main' wrapper around. This way the library could later be used by whatever is starting both the network and the 'mobile's. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Approach to system testing for Osmocom stack
rt, but the
overhead of the python "orchestration" doesn't change with the resource
footprint of the program started.
Just my thoughs, as usual. The decision is yours...
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
#!/usr/bin/env python3
import os
import logging
NUM_PROCS=2500
PROG="/bin/sleep"
logger = logging.getLogger('')
logger.setLevel(logging.INFO)
console = logging.StreamHandler()
console.setLevel(logging.INFO)
formatter = logging.Formatter('%(asctime)s %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logger.addHandler(console)
def start_proc(path, args):
return os.spawnv(os.P_NOWAIT, path, [path] + args)
logger.info("Beginning starting of processes")
p_list = []
for i in range(0,NUM_PROCS):
p = start_proc(PROG, ['3'])
if p < 0:
logger.error("Failed to start process: %d" % p)
else:
p_list.append(p)
num_started = len(p_list)
logger.info("Started %u processes" % num_started)
for i in range(0, num_started):
(pid, rc) = os.wait()
if not pid in p_list:
logger.error("not in list ?!?", t)
if rc != 0:
logger.error("Process %d exit error %d" % (pid, rc))
logger.info("Waited for all processes")
Re: TX SUPPORT
On Thu, Dec 07, 2017 at 12:41:55AM +0700, Felix Angga wrote: > Hi, > > I already uncomment the tx support in Makefile file. But when I run on > phone, it said this firmware was compiled without tx support. > > How to fix this? did you do "make clean"? Did you verify that you actually loaded the re-built file? -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmoDevCon 2018 schedule planning
Dear Osmocom Community, On Mon, Dec 04, 2017 at 01:23:47PM +0100, Harald Welte wrote: > == When, Who, Where == > > I propose the following date for OsmoDevCon 2018: > April 20 - April 23rd, 2018 > > * Who: Active developers/contributors of Osmocom projects (as usual) > * Where: IN-Berlin, Berlin (as usual) > > Please let me know ASAP if that proposed date works for everyone who'd > want to attend. We can still change it now, but I would want to nail > down the date pretty soon. > despite Holger indicating April would be difficult for him, I would still suggest to stay with the current proposed date: * nobody else has raised any concerns * several people have sent positive feedback * it's the usual time-frame as in previous years * IN-Berlin has already reserved that time slot without any conflict Sorry, Holger, I hope you will still be around as much as possible! Threfore, I hereby invite everyone interested to attend to register themselves in the usual fashion at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018 i.e. by adding your name to the 'Requested' section. Please also start collecting topics on that same wiki page. And please do let me know if there is anything we can do to make the event better. Regards, Harald > == Format == > > After the experiment of reducing from 4 to 3 days last year (due to > OsmoCon), we will again go for *four days* in 2018. > > However, we should clearly divide the days in a way that e.g. "GSM/3G" > topics are on two days, while SDR+Other topics are on the other days, so > people not interested in some topics can skip one or two days, as > needed. Let's collect the suggested topics. I've added a "Thread" column to https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018/edit?section=9 so we can see how many days / half-days we need for which thread. Regards, and looking forward to meeting you [again] in 2018, -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB layer1 with FreeCalypso changes
Hi Mychaela, also thanks from my side (I didn't have time to look at it so far, but based on your mail it seems great progress). On Sun, Nov 26, 2017 at 11:26:40PM +0700, Vadim Yanitskiy wrote: > Do you agree if I would merge your changes to the mainstream > under GNU GPL version 2 license, keeping you as the author? Thanks Vadim. It would be great to see this as patches in gerrit for review and merge. Do you have a FreeCalypso board to test? If not, we can make one remotely accessible (SSH to Linux box which has it connected to UART + USB based power cycling capability of the board power suplpy) in the sysmocom lab, if needed. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: primitives without msgb
Hi Holger,
thanks for bringing this up. The original idea of introducing osmo_prim
was for asynchronous primitives being exchanged between individual parts
of a protocol stack. I think the L1/L2 interface in OsmocomBB was one
of the first users. There we also need the async nature, as primitives
are sent over the serial line.
In other parts of the code, like the libosmo-sigtran MTP-USER-SAP or
SCCP-USER-SAP, there are still msgb-wrapped osmo_prim, despite us
currently dispatching them synchronously into the user application code.
The idea was that this could later be evolved into a system where the
related msgb's are sent over a unix domain socket between applications
to isolate the sigtran/sccp stack from the user application.
So my general "road map" for osmo_prim and related SAPs is in that
direction:
* turn SAPs into first-class citizens with infrastructure to register
them, VTY introspection, etc.
* have facilities for accessing SAPs from different processes via
unix domain sockets and exchange osmo-prim over sockets
On Mon, Nov 20, 2017 at 08:29:35PM +0800, Holger Freyther wrote:
> The neat thing about this approach is that I don't tie a specific
> scripting solution into the code, the indications are generic enough
> to be useful in multiple contexts, the submit/dispatch is about high
> level operations ("send SMS", "switch device off") that map to other
> programming languages as well. E.g. it is easy to imagine that one
> writes a TCP/IP adapter to send these primitives to another
> process/application.
I very much like this and support it. This is also how I had envisioned
this feature to move ahead: First have some primitives for those
operations, and then use those primitives from a language binding such
as lua.
> The controversial part is that this code is not using a msgb. Normally
> the primitive header is inside a msgb and then more or less points to
> itself.
Yes, and the goal of this is to have all information inside the
primitive. We don't pass pointers across a SAP. All information is
self-contained and only identifiers are used to refererence other
state/objects. This means they can be queued, transported over sockets
(at least on the same host where the struct
alignment/padding/endinanness is identical), ...
> But in the scripting layer case the "timer", "new sms", "network
> selection" are already fully parsed objects (or where never parsed
> from a network representation) so are normally not located in a msgb
> in any form.
Yes, understood. Still, those structures could probably simply be
copied/wrapped into a msgb? Like the struct that represents a parsed
SMS?
> One option is not to bother and deal with the primitive header just
> being embedded in another structure. The concept of
> request/response/indication is bigger than network messages.
correct. However, I think it might actually be good to call things
differently or to find some kind of naming to make it easy for them not
to be confused?
> The other is to create a dummy msgb to obey the interface and follow
> the existing users but I am not sure what we would gain.
We wouldn't gain anything as long as there would still be pointers or
other non-serialized data inside the msgb itself. Wrapping into a msgb
only makes sense if the msgb-wrapped-prim is self-contained.
At that point you gain that you can queue them, work asynchronosly on
them, and that e.g. a script language VM/interpreter/... could run in
a completely different process. I would love to see that, but of course
if it's only possible by crating tons of new struct definitions, copying
the data back and forth, etc. a shortcut like you proposed might be more
realistic.
But then, given that the number of high-level primitives is expected to
be rather small (perform LU, MO-SMS, MT-SMS, USSD) in theory it should
not be too much data that needs to be converted?
For call control, it occurs to me only now, we could and probably should
actually use the MNCC interface that OsmocomBB already offers. So
existing MNCC primitives (which predate osmo_prim, but which would have
been be a very good fit conceptually) can be created/used by the "script
language process/thread/binding" side to create higher-level functions
that can be used from the script language. So the script would simply
synchonously ask for make_a_mo_voice_call(msisdn) while then the
underlying C code would translate that to MNCC and use the existing
socket for that?
In the end, you are doing the work, and it's your call. I see some
benefits of going the msgb way, but then I don't understand the
implications in detail as you do, working on the given task.
Regards,
Harald
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Pri
Re: Calypso vs. SDR PHY
Hi Mychaela, On Sat, Nov 18, 2017 at 07:03:51PM -0800, Mychaela Falconia wrote: > > (5) somewhat ties into (4): One goal was always to run also 'mobile' > > inside a phone and have a FOSS-based telephone. Nobody has had > > the time + endurance to get there, and I doubt it will still happen > > at this point. > > Regarding the last part (doubting that a FOSS-based mobile phone will > still happen at this point), it most certainly will happen, but unless > you beat me to it, it will happen with FreeCalypso firmware rather > than OsmocomBB. FreeCalypso is *not* FOSS, and hence does not qualify regarding my statement above. It's not compliant to the FSF's Free Software Definition, nor the Debian Free Software Guidelines, nor under and OSI approved license for Open Source. Hence, neither Free Software nor Open Source. You may not care about that, and it is your free choice to do so, which I do respect. However, the vast majority of people has a pre-existing notion about what FOSS is. And calling FreeCalypso FOSS is what I strongly object to. > But right now you do have a great opportunity to beat me to that goal. People with an interest in OsmocomBB have that opportunity. I personally have no time for that, and I have different priorities (otherwise I would have worked on this already some 5-7 years ago, when creating OsmocomBB in the first place). > > The source code is out there. Apparently none of the (at some point many) > > OsmocomBB users has ever seen significant enough need to research and > > understand the format of those calibration tables > > Just so we are clear, the format of the RF calibration tables used by > mainline TI->Openmoko->FreeCalypso firmwares is not any kind of secret, > and there is nothing that needs to be "researched" there. Anything that is not clear / obvious to the people involve needs to be "researched". > The people who work professionally on the official firmware for the Calypso > chipset (employed formerly by TI and presently by Falconia Partners > LLC) naturally understand the meaning of every number in every RF > calibration data structure. And those people - like anyone else on the planet - are happily invited to contribute related patches to OsmocomBB, if they care about it. It appears that you care about OsmocomBB not using the calibration tables, and based on the 7 years of OsmocomBB history, nobody among the OsmocomBB users seems to care sufficiently to work on it. That's sad, but it is a fact. People do have tons of other projects and responsibilities, and steps towards regulatory compliance for a highly experimental project like OsmocomBB apparently was not on the top priority list. > Of course if OsmocomBB people don't > understand the meaning of these numbers, that's a different story... Hence, either the people who understand it contribute a patch, or the "OsmocomBB people" need to research the topic, or it will not happen. > For anyone who does wish to study the official L1 code created by the > same people who created the chips it is meant to run on, the source > for the official FreeCalypso fw (formerly TI's official fw) is public, I am sure by now everyone on this list is aware of that. > It is true that Mot C1xx phones use a different format of Mot/Compal's > own invention, not TI's, but just earlier today I finished implementing > the utility that extracts the useful numbers from Mot/Compal's > proprietary flash data structures and converts them to the mainline > TI/FreeCalypso format. You can find it in my freecalypso-tools Hg > repository: > > https://bitbucket.org/falconian/freecalypso-tools Thanks a lot, I'm sure this is an excellent pointer in case somebody wants to go ahead and implement reading of the calibration tables. > Therefore, I am considering implementing an adapter or gateway process > that would allow OsmocomBB's L23 to connect to FreeCalypso L1 instead > of OsmocomBB's own. I haven't done any serious feasibility study yet, > but I now feel that it would be worth looking into. Sure, the MS-side L1CTL interface can most likely be implemented for various different L1 implementations. It's what has been done by various groups publicly and privately before. Last but not least, the new virtphy takes the same approach: Simulate L1 in a way that's completely transparent towards L23. L1CTL is very simple and was crated very ad-hoc at the time, so be warned if you think it's not very elegant: It isn't :/ For sure it's much more work than reading + processing the calibration values, AFAICT. Kind Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Calypso vs. SDR PHY
Hi Mychaela, On Wed, Nov 15, 2017 at 10:58:08PM -0800, Mychaela Falconia wrote: > I naturally have my reservations about expending the effort to > calibrate each hardware unit I produce with utmost diligence, only to > sell them to people who are going to run firmware that completely > ignores these factory RF calibration values and runs with some > hard-coded off-the-wall numbers instead. The source code is out there. Apparently none of the (at some point many) OsmocomBB users has ever seen significant enough need to research and understand the format of those calibration tables and make use of them from OsmocomBB. It's sad, but that's the state of affairs, even 7 years into the project. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Calypso vs. SDR PHY
Hi Mychaela, On Fri, Nov 10, 2017 at 05:17:21PM -0800, Mychaela Falconia wrote: > As I understand it, there are two reasons for why the original > incarnation of OsmocomBB (prior to the recent addition of SDR PHY > support) used Calypso phones as its physical transceiver instead of > USRP-style SDR devices: (1) the work done by the Calypso DSP is > already done, hence there was less work for OsmocomBB developers to > do, and (2) Calypso phones used to be dirt-cheap, whereas SDR devices > cost some non-trivial money. Actually, it's also (3) the (particularly) receiver performance of the TIS DSP is pretty damn good and it is quite some effort to achieve comparable performance with a general-purpose SDR. You can e.g. add external band filters for downlink, but then you're still missing the analog matches 270kHz baseband filter in front of the ADC to avoid loosing any ADC resolution to nearby in-band carriers. The analog filters in integrated RFICs today typically don't go smaller than 1MHz (if at all) which is quite far from the 270kHz that GSM uses. (4) you can actually run the entire application (e.g. http://osmocom.org/projects/baseband/wiki/Rssibin) inside a small, hand-held, battery-powered device. Try that with PC + SDR and look at your size + power budget. (5) somewhat ties into (4): One goal was always to run also 'mobile' inside a phone and have a FOSS-based telephone. Nobody has had the time + endurance to get there, and I doubt it will still happen at this point. > But the dirt-cheap Calypso phone situation is now firmly in the past, > and newly made Calypso devices like my FCDEV3B are nowhere close to > cheap. It is also something to keep in mind that a lot of the people who had an interest in OsmocomBB have those phones for years. And the number of new people who haven't been around for many years with an interest in playing with "old" cellular systems such as GSM is quite low. > The qty-1 retail price for one of my FCDEV3B boards is > $500 USD; if someone were to order a large batch (say, 100 boards), > I am reasonably confident that the per-unit price can be brought down > to $300 USD or maybe even lower, Having done a fair amount of electronics manufacturing in this kind of quantity, I would seriously be surprised if you'd still be at that kind of pricing in a MOQ-100 situation. But sure, it will not be at the level of a used old phone. > Thus with the cost of an SDR device and that of a newly made Calypso > device being comparable (or as things stand presently, the Calypso > option is more expensive), is there any remaining reason to use > Calypso devices as opposed to SDR PHY for OsmocomBB? See above. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Want to do paid work on Osmocom? sysmocom is hiring
Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to j...@sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwe...@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 * Geschaeftsfuehrer / Managing Director: Harald Welte
Re: layer23/mobile: VTY is broken
Hi Neels,
On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
> Ah, damn. I checked all of the repositories I know to use the VTY, I didn't
> imagine that OsmocomBB also has a VTY. That's really my fault then.
I think in general we should not fall into that trap. We have *no clue* at all
who might be using libosmo* for whatever purpose. If we provide a libary with
a given API/ABI, then it's our responsibility to keep that ABI/API as stable as
possible.
I understand that it was hardly possible without fall-out in that particular
case, and for sure there are exceptions.
However, completely unrelated to this particular topic (and hence the Cc
to openbsc@) I'm not happy in general with the way how "carlessly" we
sometimes introduce breakage. We have to be more disciplined in general
on this. All of us.
BTW: The fact that this change has gone into master without being
noticed also means that possibly we're not modelling osmocom-bb as a
downstream user of libosmocore that needs to be rebuilt (and at least
checked if it starts up correctly?) whenever testing a libosmocore
change. That's also something to investigate. Maybe there's some way
we can test this without too much effort.
Regards,
Harald
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: GAPK status update
Hi Vadim,
On Fri, Sep 08, 2017 at 03:30:05PM +0300, Vadim Yanitskiy wrote:
> Having these projects in my mind, I have got an idea of
> creating a shared library from the GAPK source code. And,
> a few days ago I was managed to get the audio playback
> working in OsmocomBB. I hope, this library will be also
> usable for other projects.
I like this very much. Actually, this could even be used by
something like the new osmo-mgw to have more or less generic transcoding
capabilities for gsm-related codecs as well as PCM / G.711.
comments:
* the new introduced memory allocation could have been done via talloc,
but since it's just for the non-standard benchmarking case, calloc is
ok.
* it would be nice to convert all allocations to talloc, like in other
osmo-* code. This facilitates memory leak debugging.
* rather than listing all symbols individually, you can also simply
export osmo_gapk_* with a wilcard. All non-exported symbols then
have to avoid that prefix. I prefer this to long lists of symbols
that you often forget to update when adding new functions
* assuming you have multiple processing queues in a program in the
future, each queue should have a user-settable identifier which is
then used as a prefix in all the logging.
Finally, as a personal wishlist item, I would love to see some unit
tests that create a couple of processing queues, destroy them, check
if the resulting encode/decodes is what was expected, and [if possible?]
even check if allocated memory has been properly cleaned up during
destruction of the processing queue.
Let's see what Sylvain has to say about all of this, it's his creation
after all :)
Regards,
Harald
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: Re: Osmocombb on Ubuntu 16.04
On Thu, Sep 07, 2017 at 09:27:27PM +0200, Sylvain Munaut wrote: > >> arm-none-eabi-ld: section .text.exceptions VMA [0080001c,00800037] > >> overlaps section .compal.reservedram VMA [0080,008000fe] > > Yeah, IIRC the issue is that the newer GCC can't have overlapping > regions even if they're NOLOAD. Problem is that we use that in the > builds so we've just been sticking with older GCC that support > that. See also the laforge/lib-update branch where I tried to fix this some months ago (but never completed related work), specifically commit 4de980b32c09dc0697f8f84302b646d48cdbef28 Author: Harald Welte <lafo...@gnumonks.org> Date: Sun Jan 15 16:49:06 2017 +0100 WIP: Attempt to make linker scripts compatible with binutils 2.27 In binutils-2.27, one can no longer have linker sections with overlapping VMA addresses. Let's try to work around this. See https://osmocom.org/issues/1917 for more details. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB compile testing / Re: libosmocore embedded build
Hi Craig, On Thu, May 18, 2017 at 06:48:06PM +, Craig Comstock wrote: > I was thinking about how to setup an automated real device test for > the repo and/or PRs especially. I have devices and cables, just was > thinking about how to automate the re-loading of firmware (via an > interface to the power button I suppose). I think there has been some work by Peter and/or Kevin (Cc) on setting up OsmocomBB phones with a power supply (emulating a battery) and using some serial handshake line (next to the UART) to simulate power button presses in the past. Peter? Kevin? It would be great if you'd be willing to set up such as system, document it and then integate it. I think you don't even need your own base setation. Simple test cases for OsmocomBB could include: * running bcch_scan and check that certain (known strong) cells in the neigbhorhood are found * trying to register to a given network using unknwon/expired IMSI and confirming that the channel is established and a LU REJECT is received With such a test rig we could then automatically test every new libosmocore and osmcoom-bb commit to verify that it still performs basic receive and even basic rx+tx functionality. > Any work ongoing on this front? I don't think there's much happening in OsmocomBB for many years, sadly. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Creating GSM Users Association (GSMUA)
Hi Mychaela,
sorry for the late response.
I think there is a legitimate need (for decades!) to represent the
users at entities like GSMA or (much more importantly) the 3GPP and
ETSI. 3GPP (and lesser extent ETSI) is where the relevant specifiations
are written.
Such an user representation would have a role to
* identify where (new) specifications infringe on users rights
* make sure the industry at least hears about what's in the best
interest of users before they discard all of that and implement
whatever they want anyway
* Raise public awareness about new proposals for specifications that are
particularly problematic from a user point of view, therby assert
pressure on the standardizations body before it is too late (spec
finalied).
The areas that I can think of are mostly related to privacy, data
protection, and general "digital rights".
However, doing the above is fundamentally a lobbying organization, and
requires significant funding, starting from membership fees to the
relevant standard bodies, to paying for all the related travel expenses
to attend the relevant meetings, and people with lots of time on their
hands to read the respective draft standards, etc.
I think it would be great to do something here, but I think we as the
"super technical, ultra nerdy" people working on Free Software (and
harwere) in the telecom sphere are typically not in posession of the
right skillset to do so. It's much more about social skills than about
technical skills.
Regarding your proposal: It seems like a contradiction in terms to me if
you establish something called an 'user association' while your interest
is (at least partially) to represent "boutique manufacturers" regarding
IMEI allocations. That's not really of the interest of a *user*. I
think the least concern of a user is how and where a manufacturer gets
his IMEI allocated. Yes, I agree there is something that can be done
regarding TAC allocation (like IEEE OUI / MAC address allocation or USB
vid/pid allocation). But that's not a topic for users.
Regards,
Harald
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
OsmocomBB compile testing / Re: libosmocore embedded build
Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB. They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB. The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts. That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master. However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: libosmocore embedded build
Hi Andre! On Thu, May 18, 2017 at 12:08:08PM +0200, André Boddenberg wrote: > a test job for the libosmocore arm-none-eabi build is created [1]. > Another multi-configuration axis (arch) has been added and a > combination filter has been applied to not run arm builds on FreeBSD. great. > Do we actually want to cross-compile on FreeBSD as well? no. > The arm build does not succeed (yet) [2]. > > Can someone else may have a quick look at log [2] to point me in the > right direction? Afaics build dependencies are available but the > compilation itself fails. The build completes, but 'make check' fails. I think 'make check' does only make sense for host builds, but not for embedded. We cannot execute the test cases anyway, even if we were able to build them. I cannot fix it right now in the autoconf (i.e. do nothing for 'make check'), so feel free to disable 'make check' in the build script as an interim workaround. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: removing ancient libosmocore fork from osmocom-bb.git
Hi Holger,
On Wed, May 17, 2017 at 11:00:06PM +0800, Holger Freyther wrote:
> >>> * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
> >>> libosmocore.git (plus an embedded 'malloc' like umm_malloc)
> >>
> >> Why do we need this hack (pseudotalloc)?
> >
> > Because talloc is large both in terms of runtime memory overhead (for
> > each allocation) and in terms of code footprint,.
>
> related to that. How confident are you we don't rely on the hierarchical
> feature of talloc inside the libosmo* (or your more narrow list)?
Not libosmo* in general, but just libosmo{core,gsm,dsp,crypt,codec}.
However, I think we already use it in some places, although I don't
think we *rely* on it). So e.g. in osmo_fsm if you allocate child fsm's
from a parent, the children get the parent as context. However, the fsm
code itself doesn't rely on automatic free()ing of children.
There are also other features like a destructor callback which we don't
use anywhere AFAIK.
> Maybe we add some kind of runtime test/probe for that?
That could be an idea, but then that would come as a runtime overhead on
the non-embedded builds?
I think it's not really something to worry too much about it, given that
memory leaks in tiny embedded microcontrollers are found *very* quickly.
If there was a leak of some sort, chances are high that you catch it
already after a handful of allocations due to OOM.
It's also questionable whether some of the more complex constructs like
FSMs are going to be used in such environments to begin with. I think
even the logging system in its current form might want some
simplification if we want to use it there. Also, the timers could do
without rb-tree to reduce code footprint, ...
Yes, it's not nice to have that kind of possibillity for hidden
errors, but at least I'm happy with it, and there are not too many
people working on simtrace and related firmware anyway...
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
libosmocore embedded build
Dear all,
when we originally moved a lot of generic code from OpenBSC to
libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded'
build of libosmocore, which can use [most of] the library code also in
deeply embedded, OS-less 'bare metal' microcontroller environments.
The ability to build libosmocore this way has been broken for many
years, but I've fixed that in recent libosmocore master. Below command
works for me [tm]:
./configure --prefix=/usr/local/arm-none-eabi \
--host=arm-none-eabi \
--enable-embedded \
--disable-shared \
CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles
-nodefaultlibs"
What we'd need now is:
1) make sure embedded builds continue to work by building libosmocore
for embedded as part of the jenkins setup (using gcc-arm-none-eabi
debian package). Any volunteers?
2) start to use this embedded build from simtrace2 firmware, osmocom-bb
and the upcoming fimrware for the RFDN[1]. So far,
* osmocom-bb uses an old clone of libosmocore,
* simtrace2 is using some copy+pasted fork of some libosmocore files
* rfdn is using some copy+pasted fork of some libosmocore files
The above is no longer required.
3) consider if we can shrink the resource requirements of some
libosmocore parts. One issue coming up are the static buffers in
osmo_hexdump[] or the like. If your total processor RAM is 8k or
16k, then spending 4k on the buffer for hex-dumping is indeed a bit
excessive.
Any help is appreciated, particularly on the jenkins side.
Regards,
Harald
[1] (1:8 splitter-combiner with adjustible step attenuators, part of the
osmo-gsm-tester setup we're building at sysmocom). Code will be
released as soon as the hardware is validated.
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: CalypsoBTS + GPRS and SDR suggestion
Hi inode,
this list is about osmocom-bb, and not about the osmocom projects about
networks-side gsm. OsmoTRX, OsmoBTS & Co are discussed on the
open...@lists.osmocom.org mailing list. Please consider asking your
questions there.
On Mon, May 08, 2017 at 06:58:01AM +0200, inode wrote:
> but from my understanding it support only GSM calls
> and SMS and GPRS is not implemented into the transceiver. I'm wrong or this
> part has not been implemented yet?
I have never used the "calypsobts" hack. But osmo-trx + osmo-bts-trx
have support of voice, SMS and GRPS services.
As SMS is using the same signaling channels, this should definitely work
even with the CalypsoBTS. For GPRS, you'd need to support the GPRS
related coding schemes and an interface to OsmoPCU. Also, given that
CalypsoBTS can only provide single (or two?) timeslot, there are a long
list of reasons why it would not work straight-forward. But technically
also possible to make work.
> If needed to use a GPRS BTS can you suggest the best cheap SDR to use with
> OsmoBTS? (I saw BladeRF and LimeSDR but I was unable to understand if they
> are full supported via OsmoBTS)
Please raise this (and continue any related discussion) on the other
mailing list.
Regards,
Harald
--
- Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Re: gerrit for osmocom-bb
Hi Sylvain, On Wed, Apr 19, 2017 at 09:01:30PM +0200, Sylvain Munaut wrote: > I'm not sure if it's just me or if I'm using it wrong but I'm always > annoyed when I have to login to gerrit ... thanks for raising this issue. It is probably as simple as to extend the cookie expiration or something like that. That would at least already resolve '1)' + '4)' from your list. I've created https://osmocom.org/issues/2015 and https://osmocom.org/issues/2016 to track this. We'll have to see who can look into it, guess Holger and Neels are most familiar with the setup. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: gerrit for osmocom-bb
Hi Max, On Wed, Apr 19, 2017 at 03:31:52PM +0200, Max wrote: > I've just noticed that OsmocomBB is not on the list of projects at > https://gerrit.osmocom.org/#/admin/projects/ > Is this because nobody bothered adding it there yet or it's because > maintainers do > not find it suitable? If it's the latter than I'd love to see it added to > streamline > contributions and patch review process. I guess it's simply that nobody bothered to do so, as activity on OsmocomBB has been extremely low. I don't mind gerrit for OsmocomBB, not sure how the others think. One issue that I fear is that I see very little activity outside of the sysmocom team in gerrit in terms of review. I had the feeling this was better while posting patches still on the mailing lists. I'm not sure there is a causality. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: FreeCalypso GSM MS development board built and mostly works
Hi Mychaela, On Sun, Apr 09, 2017 at 01:22:03AM -0800, Mychaela Falconia wrote: > Harald invited me to share this news with this list, so here it goes: thanks for the update! > Now the following part is bad news for me, but probably good news for > you guys: right now OsmocomBB works on this board to the point of > being able to connect to the live commercial GSM network in my part of > the world, send and receive SMS and make a call, but my own preferred > firmware is not currently able to the connect to the network (fails in > the FB/SB acquisition step) because of the lack of VCXO calibration. this is good news, indeed. I'm quite sure you will get your preferred firmware working, too. > * TI's TCS211 firmware for the Calypso (the basis for FreeCalypso) > expects per-unit RF calibration to be performed on the production > line, and the VCXO calibration appears to be the most critical step: > if I delete the VCXO calibration files on an Openmoko-made GTA02, > the modem stops working (fails to acquire FB/SB in the network search > just like on my FCDEV3B), whereas all other RF calibration files can > be deleted and it still works. Hence I reason that the lack of this > VCXO calibration is the cause of my current inability to connect to > the network from my board using my preferred firmware. > Now here is the part I don't understand: how are you able to get away > with not requiring RF calibration in OsmocomBB? RF calibration generally is required for [spectrum, regulatory] conformity. For example, the transmit power OsmoocmBB currently uses on phones is more or less "random" in a sense that we have simply used one value that worked with one given unit of a C123, and assume that all other C123 are not too far off from that value. In reality, this can easily mean quite large discrepancy between intended transmit power and actual measured transmit power. For the proof-of-concept / lab type use that was the primary target for OsmcoomBB this was sufficient. See the dbm2apc_gsm900[] table for the power calibration values which most definitely are wrong on all but one phone. Also, for the VCTCXO: We don't use any calibration here at all. I am not even sure what exactly is calibrated in the Motorola or Openmoko firmware. you can see our AFC code in layer1/afc.c is simply using some constants for the slope and normalization in order to pull the frequency towards its intended target, based on the measured frequency error. The absolute accuracy of the VCTCXO doesn't matter, all that matters is the relative difference between the local clock and the recovered clock from the FCCH, and we use that to compensate. > So where is the catch? There must be some good reason why TI's TCS211 > fw requires VCXO calibration, and when the fw is redesigned to not > require such calibration as you seem to have done in OsmocomBB, > something else (something important probably) must be sacrificed. No idea, maybe it's simply some temperature curve? I suppose reading your "preferred firmware" source code should reveal more details what this data is actually used for. Doesn't it simply work if you copy the calibration data from a working phone (like GTA02) to your FCDEV3B ? -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB MNCC socket implementation without LCR
Hi Gerard, On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote: > 1) Have you or your team tried to reverse engineer/hacking Over the Air OTA > spec - firmware upgrade (understanding this type of communication) using > OpenNITB and latest phones where bootloaders are locked? I haven't looked at this personally, but several people have looked at security of several different OTA updates for about a decade by now. The main issue is that there is no standard protocol or system, and everyone cooks up their own. > - I was planning to try this! But now I will take up merging osmo-sim-auth > and py-sim. (I'm not a great dev but I'm passionate about osmocom and > willing to contribute my time to learning/contributing the same). thanks! > 2) I have been trying something different with OsmocomBB, osmo-sim-auth and > Tor lately - I would like to hear your views on the same. > Attack Model: Geo-Location Anonymous calling in GSM. > > Description: > 1. The attacker uses OsmocomBB phone to make a call using a sim card > service. (No sim card present in the phone). > 2. For this, I have taken the SIM card outside OsmocomBB and re-written all > SIM API's in osmo-sim-auth (which is the sim card service). > 3. This sim card service is deployed over Tor network, so no one can > actually know the location of the SIM card service. > 4, The osmocombb connects to the network and uses this sim card service for > authentication etc. > 5. The whole setup of calling etc is initiated by the sim card service, > which is itself behind Tor. This is basically the sim card forwarding / remote SIM, which people have been experimenting on SIMtrace for quite some time. In this case you can use any regular phone or modem, and don't need osmocombb. There is a complete 'remote sim / card emulation' proof of concept in the simtrace2.git repository, but this requires a prototype of the simtrace 2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware (with SAM7). Also, there are plenty of commercial suppliers of systems like you have described. a) in the area of automatic roaming testing (between operators) b) in the area of automatic service quality testing (between operators) c) in the grey area of so-called SIM-boxes, where you have hundreds to thousands of SIM cards in one data center, which you can remotely provision to any number of "GSM VoIP gateways" spread in different countries. This is typically used for interconnection fraud by shady operators. None of the above use Tor (as they have different use cases), but the option 'c' at least also uses IMEI randomization to avoid tracking the subscriber via his IMEI, which presumably you would want to do in your OsmocomBB based system, t.. > 6. Now, This SIM card service can be used my multiple phones, so now you > are not exactly going to track the phone since if I use the SIM card > service to another phone (cell area) the DB entry in VLR has changed which > says the location has changed. Yes, but you have to be very quick. Of course from the time of the LU throughout the call, your position is known to the observer. Not because of your IMSI or IMEI (which you both keep changing) but because of the phone numbers you call. It depends on what you want to defend against. Basically you can do this already if you carry around a huge bag of sim cards which you always only use for a single call, *and* you have a phone that can change the IMEI every time you change the SIM. This is apparently what e.g. human rights activists in hostile countries are doing. However, the biggest problem in such situations is not your own identity, but the identities you contact. So if you keep calling the same destination number, all of the above is useless as the key to find you is by the destination number. So at the same time, you require a potentially large number of phone numbers that are not in some way associated to another (and at best in different countries), which then provide call redirect to your real destination. > 7. My experiments worked well on a LIVE network, understanding the delay in > Tor the network, still, the BTS was accepting RES response challenge from > the SIM card service behind Tor - I still have to calculate the exact max > acceptable delay in sending RES back to BTS to confirm this! I think I remember that at least 2 if not 4 seconds of delay are acceptable for the complete authentication handshake. People are even doing this over satellite back-haul. -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: OsmocomBB MNCC socket implementation without LCR
Hi Gerard, On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote: > GSM_TAP was the key - Thank you for this help. External CC works well now. great. > Just compared mncc with internal and external CC - Debugged a little > further and realized 1 of the fields of bearer_cap was missing! > mncc-python is good - I read your blog. Made some changes (socket path). > Although it does fail with "Invalid mandatory information" - bearer cap > missing. I will have to look again at the code. Patches are always welcome. I guess mncc-python is so far only used with OsmoNITB, and not with the MS-side MNCC on OsmocomBB. But it would be great to have this working, too. > Osmo-sim-auth and pysim both same projects right? no. osmo-sim-auth just performs a (GSM or UMTS) authentication against a SIM card. pySim is for programming certain cards where that is possible (like MagicSIM, sysmoSIM, sysmoUSIM, etc.) I think there are two distinct purposes and it makes sense to have two different tools. But yes, it probably could make sense to merge the code in one repository and simply have multiple executables for that. Would you be interested in merging the two, i.e. provide an incremental patchset against pysim that adds the osmo-sim-auth binary? > Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was > planning to push upstream and then realized there is a project pysim which > has all of that ? Sorry to hear that. pySim-prog actually existed for much longer time, it is what we always used to program SIM Cards ever since 2009. -- -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Connecting OsmocomBB to OpenBTS
Hi Usama, "Osmocom" is a very large umbrella project, of which OsmocomBB is only one small part. So when referring to OsmocomBB, please always use the full name, to avoid confusion. Thanks! On Sat, Mar 25, 2017 at 07:39:33PM +0500, Usama Muneeb wrote: > I recently set up OpenBTS which is working perfectly. I can make a test > call by calling 2600 using an Android phone. In case you're interested, you can also use the Osmocom stack (OsmoTRX+OsmoBTS+OsmoNITB) on the network side. > However when I try "show subscriber" in OSMOCOM, various BTS are listed, > with their MNC and MCC values but OpenBTS is not listed. I'm puzzled. Why would "show subscriber" list any BTSs ?!? Please provide the actual copy+paste output of what you are referring to. >From what I can tell, "show subscriber" lists the preferred PLMNs and the forbidden PLMNs as stored on the SIM card. This makes sense, as they are attributes related to the subscriber. But listing visible BTS on the subscriber somehow wouldn't even make sense, IMHO. Regards, Harald -- - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
