Hi!
I am finishing an app in c++ for A5/3 rainbow tables on cuda.
Is somebody interested in sharing nvidia GPU for generating or costs for
cloud?
Regards!
пон, 23. окт 2023. у 14:04 <baseband-devel-request(a)lists.osmocom.org> је
написао/ла:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."Today's Topics:
>
> 1. Powering GSM MS from USB (Mychaela Falconia)
>
>
>
> ---------- Forwarded message ----------
> From: Mychaela Falconia <falcon(a)freecalypso.org>
> To: baseband-devel(a)lists.osmocom.org, community(a)freecalypso.org
> Cc:
> Bcc:
> Date: Sun, 22 Oct 2023 15:40:49 -0800
> Subject: Powering GSM MS from USB
> Hello fellow GSM MS tinkerers,
>
> Question: is there anyone on either ML who has any experience with
> powering a GSM MS from USB, or had at least thought about this problem?
>
> We all know the fundamental problem: during Tx bursts the PA in a GSM
> MS can suck as much as 2 A, but the current budget of a classic USB
> port is only 500 mA. However, that 2 A current draw has a duty cycle
> of 1/8 of a TDMA frame, and the total energy transfer with 1/8 duty
> cycle bursts of 2 A (at a given voltage) is equivalent to 250 mA
> continuous draw - and the latter number is well within the range of
> what a PC/laptop USB host port can supply.
>
> Context: I am looking into the possibility of building a new GSM MS
> board that would be just a little better than the one in OS#4030. The
> goal is to produce a low-cost modem-only (no UI as in LCD etc, host
> computer required for control) GSM MS using a pre-existing packaged
> Calypso module (FC Tango, similar to GTM900, but a little better) with
> a built-in USB adapter for the two Calypso UARTs - very similar goals
> to OS#4030, but design it in such a way that will be suitable for both
> firmware tastes, rather than OBB-only.
>
> My initial thought was to require a separate non-USB supply for the
> GSM side of this board, leaving USB power only for the FT2232H block.
> This approach is not a problem from the perspective of cost - I
> already have a large stock of 3.6V 2.2A power supply bricks that were
> specifically made for powering FreeCalypso dev boards, hence the
> least-effort and least-cost approach would be to simply include one of
> these AC-to-3.6V adapters with each board and be done with it. But
> use convenience does suffer with this approach: in addition to
> connecting the GSM MS board to her PC/laptop with a USB cable, the
> user would also have to connect the separate 3.6V power supply (and
> have a spare AC power outlet for it) in order to bring the GSM MS to
> life.
>
> The whole arrangement would be much more convenient for the user if
> she only needs to connect USB from her PC/laptop to the board and
> that's it - have this USB supply power to the GSM MS and carry the two
> ttyUSB channels for Calypso UARTs. But how to design it in hw so that
> it will work correctly is the question.
>
> My first thought in this direction is to implement a step-down
> regulator (ideally a switcher, but linear may be OK too) from 5V down
> to 3.5V as the first order of business, and then somehow deal with 2 A
> current spikes on the 3.5V rail. Why 3.5V? Every power consumer
> inside a Calypso+Iota+Rita module either uses actual LDO linear
> regulators (Iota and Rita) or behaves (power-wise) in the manner of a
> linear regulator (RF PA), thus one could actually feed 5V directly to
> the VBAT input of such module - but this design would shorten the
> longevity of components through higher heat dissipation inside Iota,
> Rita and PA chips. If we stick a linear regulator down to 3.5V
> somewhere between USB 5V power input and VBAT rail to the Calypso
> module, the overall current and power consumption profile stays
> exactly the same, but a big chunk of heat dissipation moves from
> delicate RF components to that external 3.5V regulator, which can have
> a proper heat sink. (The specific choice of 3.5V number is rather
> arbitrary - the idea is to make it as low as possible while staying
> within safe margins of "good battery" voltage.) And if we make that
> 5V to 3.5V regulator a switcher instead of linear, we'll have a little
> less current drawn from the USB host for the same current into VBAT
> GSM domain.
>
> 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?
> 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 greatly appreciate some feedback on these ideas.
>
> M~
>
> P.S. Suggestions to move to USB Type C and USB-PD won't be helpful -
> the dev board MUST be usable with traditional PC/laptop USB host ports
> that max out at 500 mA and never switch from 5V to any other voltage.
> _______________________________________________
> baseband-devel mailing list -- baseband-devel(a)lists.osmocom.org
> To unsubscribe send an email to baseband-devel-leave(a)lists.osmocom.org
>
For my thesis research, I am looking for a 3G protocol stack that enables users can call each other and make data connections. If I can, I need to establish 7-8Mbps for downlink in lab environment. Is it even possible, I don’t know yet? Besides, I am sure you know if I can make a call connection between 2G and 3G users via Osmocom. This is my another possible research subject. Thank you very much in advance for your answers. Best Regards,
Hello, I am a student at Kocaeli University. I am looking for open source software stack for 3G like OpenAirInterface for 5G or Osmocom for 2G for my work. (Osmocom has partial support for 3G)
I request you to direct me to the right resource that may know.
Thanks for your time and interest.
Kind regards,
Hello GSM MS communities,
I have a large inventory of FC Caramel2 boards that are in need of
loving homes. I mean these boards:
https://www.freecalypso.org/members/falcon/Caramel2/c2-fully-assembled.jpeg
For those who are familiar with FCDEV3B, Caramel2 boards are very
similar: all FreeCalypso tools work exactly the same (even with the
same -h fcfam target selector option), firmware functionality works
exactly the same (fcdev3b and tangomdm fw builds are made from the
same source, just minor electrical diffs between the two boards which
the fw needs to know about), same AT command interface, same rvinterf,
same everything. Vadim (fixeria) recently told me that he found FC to
have better CSD support than any other commonly available commercial
GSM modem - this aspect will work exactly the same on C2 as on FCDEV3B.
And for those who have an irresistible need to be naughty boys and run
naughty software, OBB can run on Tango/Caramel2 hardware too:
https://gerrit.osmocom.org/c/osmocom-bb/+/34297
The main diff between FCDEV3B and Caramel2 is that C2 came out a little
worse in terms of quality:
* FCDEV3B analog audio circuits (loudspeaker and mic) came out very
clean despite no special effort at design time: I never hear any "buzz"
from rectified GSM RF in FCDEV3B analog audio. OTOH, with C2 the audio
is dirty by default, and to get it mostly-clean, I have to insert a
long coax between the antenna connector on the board and the actual
antenna, to move the radiating element away from the analog audio
circuits.
* LEDs: the single green LED on FCDEV3B indicates 100% reliably if the
chipset is switched-on or switched-off, but Caramel2 board LEDs
sometimes exhibit erratic behaviour as a result of wayward current
paths, as I explain in the Status Report and User's Guide document:
https://www.freecalypso.org/pub/GSM/FreeCalypso/Tango/Caramel2-SR-UG-v1.2.p…
Seeing that Caramel2 design is flawed, I won't be making any more of
them: *if* I decide to produce another board in the future with similar
functionality, it will need to be a new design, adding LVC buffers for
proper PPD support (partial power-down) and reworking the audio
circuits. In this light, the existing inventory of C2 boards needs to
be put on clearance - they are just gathering dust right now, but they
should be perfectly suitable for more casual users with less stringest
quality requirements.
I have enough stock to supply 12 complete kits consisting of:
* Caramel2 main board;
* FT2232D-based DUART28 adapter board;
* Power adapter from universal AC (worldwide voltage and frequency
range) to 3.6 VDC;
* Possibly FC-HDS4 headset and quadband GSM antenna.
Once again, this board is a *clearance* item - no more will be made,
but the already-made ones are looking for loving homes.
*IF* there is any community interest in these boards, I would be happy
to ship a few to Sysmocom, to be further distributed via the webshop.
It would also be helpful if those who are interested in these clearance
boards (if any) could state what they would consider to be a fair price
for a full kit as described above.
M~
P.S. If anyone still does CalypsoBTS hacks, these boards would NOT be
a good choice for it, as the Rx SAW filters are totally inaccessible
to rework - all 4 SAW filters (for full quadband Rx) are integrated
into a monolithic chip-like module from Epcos, which is then embedded
into the TR-800 module which is not amenable at all to rework. However,
if you merely wish to see what's inside that TR-800 module, without
modifying it, we have published results of a complete PCB reverse eng
job on it:
https://www.freecalypso.org/pub/GSM/iWOW/TR800-reverse-eng-gerbers.tar.bz2https://www.freecalypso.org/pub/GSM/FreeCalypso/Tango/FC-Tango-netlist.tar.…
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 Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Bastien Baranoff wrote:
> Hello all, the attack : you generate the rainbow tables for each possibles ki
> with a given rand set, send this rand (which is not random ;) the phone
> respond with sres you make the operation for 3 or 4 rand and meaningly
> decrease the possibility of ki. Do you think it is realisable ?
Someone please correct me if I'm wrong on this detail, but it is my
understanding that no mainstream commercial operator today (outside of
personal enthusiast tinkerers in Osmocom and similar communities)
issues native 2G SIM cards any more - instead all of their current SIM
cards are actually USIM/ISIM, and if GSM 11.11 SIM operation is
supported at all, it is only provided as a backward compatibility
mode. I reason that these "modern" SIMs must be using Milenage in
their native 3G/4G mode, thus their secret key material is not classic
Ki, but K/Ki (128 bits) plus OPc (another 128 bits), for a total of
256 bits of secret key material.
What happens when these "modern" SIMs are accessed via GSM 11.11 SIM
protocol, or when 2G authentication is requested in a USIM session?
I find it doubtful that they switch to COMP128 (any version) in this
mode, instead I reason that they use 2G mode of Milenage, which still
uses both K/Ki and OPc - thus the secret key material used even for 2G
Kc and SRES generation from RAND is still 256 bits rather than 128.
Again, someone please correct me if my reasoning is wrong here.
M~
Hello,
I am new to this Project and I am having a Problem with running the
Transceiver. I hope you can help me out.
When i start the Transceiver on 2 Phones with this commands
./osmocon -p /dev/ttyUSB1 -m c123xor -s /tmp/osmocom_l2 -c
/root/osmocom/osmocom-bb/src/target/firmware/board/compal_e88/trx.highram.bin
./osmocon -p /dev/ttyUSB2 -m c123xor -s /tmp/osmocom_l2.2 -c
/root/osmocom/osmocom-bb/src/target/firmware/board/compal_e88/trx.highram.bin
and
sudo ./transceiver -e 1 -2 -a 47 -r 99
it throws an error which i can not solve. Maybe i am blind or something,
but it doesn't work. I tried to kill the process but i can't find anything.
The CLI gave me this error:
~/osmocom/osmocom-bb/src/host/layer23/src/transceiver# sudo
./transceiver -e 1 -2 -a 47 -r 99
47
41
1
<000c> l1ctl.c:77 Tx Reset Req (1)
<000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 '
<000c> l1ctl.c:77 Tx Reset Req (1)
<000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 '
Aborted
Even when i try to start it with only 1 Phone, it doesn't run. There is
a Problem, but i can't figure out what it is...
I hope you can help me out for running my Transceiver or give me some hints.
Thank you very much
Sally
Hi guys,
First of all, I want to reassure all the ML members that this is an
isolated pseudo spam post and I asked in advance for permission from Harald
to post it.
Said that... I just wanted to let you know that ZTE is opening a
CyberSecurity Lab in Germany and they are looking for Security Engineers
passionate about Telco Security.
*Position: *
Cybersecurity Engineer
*Location:*
Düsseldorf, Germany
*Responsibilities**:*
1. Testing the the security performance (at least but not limited to
penetration testing) of ZTE products. Drafting documents and reporting
testing results to stakeholders.
2. Participating in security research activities and projects in the
Telecommunication field. Study and use cutting-edge security
technology/tools for test and research.
3. Participating in product security risk analysis and security
requirements collection.
4. Participating in lab operations.
5. Participate in the product security incident response, trace the
attack, and give rectification plans.
6. Assisting in security certifications, support security vulnerability
verification and rectification of products.
7. Assisting in communicating security-related matters on products
across multiple departments
*Link for applications:*
https://www.linkedin.com/jobs/view/3361789707/
In case of questions, feel free to ping me here or reach me on LinkedIn [1]
Cheers
Luca
[1] https://www.linkedin.com/in/lucabongiorni/
Hello,
i'm stucking at running my transceiver. it should be working, but it
doesn`t.
if i am trying to run both transceivers with:
root:~/osmocom/osmocom-bb/src/host/osmocon #? $ ./osmocon -p
/dev/ttyUSB1 -m c123xor -s /tmp/osmocom_l2 -c
/root/osmocom/osmocom-bb/src/target/firmware/board/compal_e88/trx.highram.bin
root:~/osmocom/osmocom-bb/src/host/osmocon #? $ ./osmocon -p
/dev/ttyUSB2 -m c123xor -s /tmp/osmocom_l2.2 -c
/root/osmocom/osmocom-bb/src/target/firmware/board/compal_e88/trx.highram.bin
this one here doesn`t work like it did before. It shows me this Error
here. What can ido to get rid of this Error? Can i kill the Process of
the TRX or restart it?
root:~/osmocom/osmocom-bb/src/host/layer23/src/transceiver #? $ sudo
./transceiver -e 1 -2 -a 47 -r 99
47
41
1
<000c> l1ctl.c:77 Tx Reset Req (1)
<000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 '
<000c> l1ctl.c:77 Tx Reset Req (1)
<000c> l1ctl_link.c:171 Sending: '0d 00 00 00 01 00 00 00 '
Aborted
it would be nice to hear from you. thanks
msfu777
Hello,
I found 3x C155, 1x C116 while cleaning out my attic.
I there is somebody interested in this devices? I would be happy to give
them to the community.
muebau