From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: data to the network by using the RSL RLL DATA REQUEST primitive. Also, while we are tuned to any BCCH/CCCH, the L3 frames are sent from L2 to L3 in RSL RLL UNIT DATA INDICATION messages. What is not as simple is the non-RLL part, i.e. sending the first RACH request, ... For those, we will have to invent our own new RSLms message types, possibly reusing as many RSL information elements as possible - meaning we can share more code/structure with what we already have in libosmocore/openbsc > is there a better (simpler) way? The RSLms approach might not be the simplest one, but I think it would be a very nice/orthogonal approach. Plus: In this model, we can eventually move the L2 implementation into the MS firmware, while talking RSLms over HLDC to L3 on the PC. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: without having to go through the real layer1 or at least without having to go through the air. But without a clear path to later porting this on a real physical layer1, there would be little motivation of doing all that work. I think what makes OsmocomBB special is the very fact that we do not have to rely on simulation, but can do the "real thing". Nonetheleess, if somebody was interested in implementing what I've described, I'd be more than happy to help any such project and include the neccessary support in OpenBSC and/or OsmocomBB. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: without having to go through the real layer1 or at least without having
to go through the air.

But without a clear path to later porting this on a real physical
layer1, there would be little motivation of doing all that work.

I'd like to get involved in that, however these are my p= roblems:
- I have no running system that I could debug and
=A0 there= by learn how GSM works.
-=A0 To=A0 get a running system I would need to implement a software
=A0= =A0 only system, however, I cannot implement that without knowledge
=A0= =A0 of GSM
=A0That is kindof a deadlock.

Therefore I wonder wea= ther the expert of GSM would share their
knowledge in the obove described way:
Having=A0
=A0 - a flow diagram=
=A0 - the etsi standard pages (or simple rewrites of it)
=A0 - the h= tml parsed imlemention of a real TSM30 stack implement.
and linking that= all together to get a way for a newbie to
get started.
=A0

I think what makes OsmocomBB special is the very fact that we do not
have to rely on simulation, but can do the "real thing".

Nonetheleess, if somebody was interested in implementing what I've
described, I'd be more than happy to help any such project and
include the neccessary support in OpenBSC and/or OsmocomBB.

--
- Harald Welte <laforge at gnumonks= .org> =A0 =A0 =A0 =A0 =A0 http://laforge.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
"Privacy in residential applications is a desirable marketing option.&= quot;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0(ETSI EN 300 175-7 Ch. A6)

--0016e65ae6825c4265048170c62d-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: stage. Any ideas? If I boot the phone and use 57600bps I get some prints and then AT returns OK, no other AT commands work. In case it is too broken I have ordered a C121 from germany as well. /Erik From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: not always 100% perfect (it depends on the phone and the cable), so moving the phone during the download may cause the connection to be interrupted. I have not yet looked at the serial signal with an oscilloscope to see if there are problems with the signal itself. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: or 6225 CPUs (need to look for documentation): --- MT6225BA CECT V8 TianShiDa TS822 --- MT6225/6225A CECT 388 CECT 98 CECT 2618 CECT N95i ChangHong 868 ChuangWei T508 DaXian X889 DaXian X769 GaoXinQi D808 Hantai HT622 Hantai HT6868 JingLi H9 (some H9 also have MT6226) JinPeng A918 JinPeng 858 JinPeng A9 JinPeng S3506 JinPeng 2298 JinPeng L818 JinPeng A608 TianYu D170 TianYu B898 TianYu A930 TianYu B926 TianYu A908 ZTC 6988 ZTC 598 ZTC 1118 ZTE ZTLV900 ZTE ZT688 (note MT6205 versions also exist) --- MT6223PA TianYu B5010 CECT D1088 Next steps for me: Scan the schematics stuff and put it online. Find some 6223/6225 based phones that are cheap & suitable for hacking, i.e. ideally with some nice test points or JTAG. Other common MTK chips are 6205, 6217, 6218, 6219, 6226, 6228. One word of caution - the above lists, and documentation we start digging up, may give a false impression of predictability. In reality the brand names and model numbers are a total mess in China. Typos everywhere. All sorts of things are printed on cases & boxes, chips are changed without anybody noticing or caring. There are endless smaller Chinese brands making phones with 6223 or 6225 chips, but I think it will be very hard to use them as a stable source, to get phones with the same chips over time. So I think it's better to focus on the somewhat bigger Chinese brands as listed above. Wolfgang From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: \subsection{How to synchronize the GSM TDMA multiplex} As part of the BCCH, the BTS not only sends the FCCH but also the Synchronization CHannel (SCH). The Synchronization channel indicates the current GSM time / frame number (skipping the 3 least significant bits). By using this received GSM time and incrementing it every time the GSM bit-clock timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. Understanding the multiple layers of time multiplex such as the 26/51 multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all the logical channels of GSM. \section{Miscellaneous Topics} \subsection{GPRS} GPRS was the first packet switched extension to GSM. In fact, it is much more its entirely own mobile network, independent of GSM. The only parts shared are the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful coexistence between them. The L1 and L2 protocols are very different (and much more complex) than GSM. So while the phone baseband hardware did not need any modifications for a basic GPRS enabled phone, the software needed to be extended quite a lot. \subsection{EDGE} EDGE is a very small incremental step to GPRS. It reuses all of the time multiplex and protocol stack, but introduces a new modulation: 8PSK instead of GMSK to increase the bandwidth that can be transmitted. So while the software modifications from GPRS to EDGE are minimal, the 8PSK modulation scheme has a significant impact on the DSP, ABB and even RF Frontend (especially the RF Amplifier). \subsection{UMTS} UMTS (sometimes called WCDMA) is an entirely separate cellular network technology. Its physical layer, modulation schemes, encoding, frequency bands, channel spacing are entirely different, as is the Layer1. UMTS Layer2 has some resemblance to the GPRS Layer2. UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. Given the vast physical layer and L1 differences, a UMTS phone hardware design significantly differs from what has been described in this document. Notwithstanding, all known commercial UMTS phone chipsets as of today still include a full GSM modem in hardware and software to remain backwards-compatible. \subsection{Dual-SIM and Triple-SIM phones} In recent years, a large number of so-called {\em Dual-SIM} or even {\em Triple-SIM} phones have entered the market, particularly in China and other parts of East Asia. Those phones come in various flavours. Some of them simply have a multiplexer that allows electrical switching between multiple SIM card slots. This is similar to replacing the SIM card in a phone, just without the manual process of mechanically removing/inserting the card. As a result, you can only use one of the two SIMs at any time. The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, that's right! They contain two full GSM phoen chipsets, i.e. 2 antennas, 2 rf frontends, 2 analog basebands, 2 digital basebands, ... However, they use the same trick as smartphones: One of the two baesbands does not have keypad or display and is simply a GSM modem connected via serial line to the other baseband processor. So if a smartphone (as defined in this document) is a GSM modem connected to a PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone in one case. Triple-SIM phones often combine the two approaches, i.e. they contain two complete GSM baesband chips, but three SIM slots that can be switched among the base bands. Only two SIMs can be active at the same time. \subsection{Powerful feature phones} Feature phones are becoming more and more powerful. However, their comparatively lower market price cannot afford a full-blown smartphone design with its two independent processors and the associated design complexity. Thus, more and more hardware peripherals are added to the only processor left in the phone: The baseband processor. Such peripherals include sophisticated camera interfaces, high-resolution color display controllers, TV output, touchscreen controllers, audio and video codecs and even interfaces for mobile TV reception. However, all of those features are still implemented on a fairly weak ARM7 or ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They also lack a real operating system and still run on top of a real-time microkernel intended for much less complex systems. They almost always lack any form of memory protection or multiple address spaces. This makes them more prone to security issues as there is no privilege separation between the GSM protocol stack and the applications, or between the applications themselves. \section{Personal rant on the closedness of the GSM industry} The GSM industry is one of the most closed areas of computing that I've encountered so far. It is very hard to get any hard technical information out of them. All they like to spread is high-level marketing information, but they're very reluctant when it comes down to hard technical facts on their products. If you want to build a phone, you need to buy a GSM chipset for your product. There are only very few companies that offer such chipsets. The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI (now MediaTek) and Freescale. The GSM handset products they sell are not generally available and distributed like other electronic component they manufacture. If you need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth chip, RFID reader ASIC, you simply approach the respective distributors and order them. You get your samples directly from Digikey. This is impossible for GSM (or other cellphone) chipsets. For some reason those chips are sold only to hand-picked manufacturers. If you want to qualify, you have to subscribe to at least six-digit annual purchasing quantities. And in order for them to believe you, you have to cough up a significant NRE (non-refundable engineering fee). This has been reported as high as a seven-digit US\$ amount and is to make sure that even if you end up buying less chips than you indicate, the chipset maker will still have your upfront NRE money and keep it. And if you buy your way into that select club of cellphone makers, what you get from the chipset maker is typically not all too impressive either. The documentation you get is incomplete, i.e. it alone would not enable you as a cellphone maker to make any use of the hardware, unless you license the software (drivers, GSM protocol stack, ...) from the chipset maker, too. On the software side, most of the technologically interesting bits (like the protocol stack) are provided as binary-only libraries, you only get source code to some parts of the systems, i.e. some hardware drivers that might need modification for your particular phone electrical design. That GSM protocol stack was not written by the chipset maker either. They simply license a stack from one of the estimated 4 or 5 organizations who have ever implemented a commercial GSM protocol stack. It is not like the GSM protocols were some kidn of military secret. They are a published international standard, freely accessible for anyone. So why does everybody in that industry think that there is a need to be so secretive? Having spent a significant part of the last 6 years with reverse engineering of various aspects of mobile phones in order to understand them better and do write software tools for security analysis, I still don't understand this secrecy. All the various vendors do more or less the same. The fundamental architecture of a GSM baseband chip is the same, whether you buy it from TI, Infineon or from MediaTek. {\em They all cook with water}, like we Germans tend to say. The details like the particular DSP vendor or whether you use a traditional IF, zero-IF or low-IF analog baseband differ. But from whom do they want to hide it? If people like myself with a personal interest in the technical aspects of mobile phones can figure it out in a relatively short time, then I'm sure the competiton of those chipset makers can, too. In much less time, if they actually care. This closedness of the cellular industry is one of the reasons why there has been very little innovation in the baseband firmware throughout the last decades. Innovation can only happen by very few players. Source code bugs can only be found and fixed by very few developers at even fever large corporations. No chance for a small start-up to innovate, like they can in the sphere of the internet. It is fundamentally also the reason why the traditional phone makers have been loosing market share to newcomers to the mobile sphere like Apple with its iPhone or Google with its Android platform. Those innovations really only happened on the application processor on high-end smartphones. The closed GSM baseband processor had to be accompanied by an independent application processor running a real operating system, with real processes, memory management, shared libraries, memory protection, virtual memory spaces, user-installable applications, etc. They still don't happen on the baseband processor, which is as closed as it was 15 years ago. \end{document} --0ntfKIWw70PvrIHh-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: \subsection{How to synchronize the GSM TDMA multiplex} As part of the BCCH, the BTS not only sends the FCCH but also the Synchronization CHannel (SCH). The Synchronization channel indicates the current GSM time / frame number (skipping the 3 least significant bits). By using this received GSM time and incrementing it every time the GSM bit-clock timer wraps at the beginning of a new TDMA frame, the GSM time is synchronized. Understanding the multiple layers of time multiplex such as the 26/51 multiframe, superframe and hyperframe, the L1 can multiplex and demultiplex all the logical channels of GSM. \section{Miscellaneous Topics} \subsection{GPRS} GPRS was the first packet switched extension to GSM. In fact, it is much more its entirely own mobile network, independent of GSM. The only parts shared are the GSM modulation scheme (GMSK) and time multiplex, in order to ensure peaceful coexistence between them. The L1 and L2 protocols are very different (and much more complex) than GSM. So while the phone baseband hardware did not need any modifications for a basic GPRS enabled phone, the software needed to be extended quite a lot. \subsection{EDGE} EDGE is a very small incremental step to GPRS. It reuses all of the time multiplex and protocol stack, but introduces a new modulation: Offset 8-PSK instead of GMSK to increase the bandwidth that can be transmitted. Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid zero-crossings in the modulator output. So while the software modifications from GPRS to EDGE are minimal, the 8PSK modulation scheme has a significant impact on the DSP, ABB and even RF PA design. \subsection{UMTS} UMTS (sometimes called WCDMA) is an entirely separate cellular network technology. Its physical layer, modulation schemes, encoding, frequency bands, channel spacing are entirely different, as is the Layer1. UMTS Layer2 has some resemblance to the GPRS Layer2. UMTS Layer3 for Mobility Management and Call Control are very similar to GSM. Given the vast physical layer and L1 differences, a UMTS phone hardware design significantly differs from what has been described in this document. Notwithstanding, all known commercial UMTS phone chipsets as of today still include a full GSM modem in hardware and software to remain backwards-compatible. \subsection{Dual-SIM and Triple-SIM phones} In recent years, a large number of so-called {\em Dual-SIM} or even {\em Triple-SIM} phones have entered the market, particularly in China and other parts of East Asia. Those phones come in various flavours. Some of them simply have a multiplexer that allows electrical switching between multiple SIM card slots. This is similar to replacing the SIM card in a phone, just without the manual process of mechanically removing/inserting the card. As a result, you can only use one of the two SIMs at any time. The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, that's right! They contain two full GSM phone chipsets, i.e. 2 antennas, 2 rf frontends, 2 analog basebands, 2 digital basebands, ... However, they use the same trick as smartphones: One of the two basebands does not have keypad or display and is simply a GSM modem connected via serial line to the other baseband processor. So if a smartphone (as defined in this document) is a GSM modem connected to a PDA in one case, a Dual-SIM phone is a GSM modem connected to a feature phone in one case. Triple-SIM phones often combine the two approaches, i.e. they contain two complete GSM baseband chips, but three SIM slots that can be switched among the base bands. Only two SIMs can be active at the same time. \subsection{Powerful feature phones} Feature phones are becoming more and more powerful. However, their comparatively lower market price cannot afford a full-blown smartphone design with its two independent processors and the associated design complexity. Thus, more and more hardware peripherals are added to the only processor left in the phone: The baseband processor. Such peripherals include sophisticated camera interfaces, high-resolution color display controllers, TV output, touchscreen controllers, audio and video codecs and even interfaces for mobile TV reception. However, all of those features are still implemented on a fairly weak ARM7 or ARM9 CPU core (compared to ARM11 and Cortex-A8 in the smartphone market). They also lack a real operating system and still run on top of a real-time microkernel intended for much less complex systems. They almost always lack any form of memory protection or multiple address spaces. This makes them more prone to security issues as there is no privilege separation between the GSM protocol stack and the applications, or between the applications themselves. \subsection{Security features} There are several (sometimes conflicting) security requirements that apply to mobile phones. Interestingly, the security features are typically used to protect some industry interest against the interest of the customer. There are very few security features in a phone that are meant to protect the user or his interests. \subsubsection{IMEI - The hardware serial number} The International Mobile Equipment Identifier (IMEI) uniquely identifies a GSM phone. It is a globally unique serial number which is programmed into the phone non-volatile memory (Flash or EEPROM) during the production process. There are no particular security features used to store the IMEI. Once you are able to write to flash and have found it, it can be changed. \subsubsection{The SIM Card} The SIM card is a cryptographic smart card that stores the secret key used for authenticating the user to the GSM network (Ki). The Ki is never released by the card, and as such copying (cloning) of the SIM is prevented. Furthermore, the SIM stores the International Mobile Subscriber Identity (ISMI). The IMSI is not encrypted or protected in some way. There is no security channel on the connection between the SIM card and the baseband MCU. Furthermore, there is no way how the MCU can securely identify/authenticate the SIM itself. Physical access to the SIM card slot allows sniffing and/or modification of the communication between MCU and SIM. \subsubsection{SIM or Operator Locking} GSM is an international standard. This ensures interoperability, i.e. any phone can be used on any network. However, in some cases, the vendors of a GSM phone want to restrict this interoperability and lock a phone to one specific network, or even lock it to a particular SIM. Those locks are implemented by software only, i.e. the MCU software will instruct the GSM protocol stack not to register with a network unless its network operator code is a certain factory-programmed network number. As such, techniques for circumventing those locks have become commonplace. It's somewhat of an ongoing race between the phone makers and the phone-unlockers. The industry invents ever more complex methods of obfuscating their locks in the software, while the phone-unlockers reverse engineer those bits for each and every phone model after some time. \subsubsection{DBB firmware signatures} In order to protect the operator and phone manufacturers peculiar business models based on SIM or operator locking, some vendors extended their baseband software with cryptographic signatures. Only if the correct signature is present in a software update, the bootloader program will accept the new software. However, there are more or less invasive hardware-related approaches in circumventing those signature checks, such as hardware debugging interfaces like JTAG, or replacing the external flash memory components. More recently, GSM chipset vendors introduced features such as hardware-assisted software signature checks. In this case a master key hash might be present in DBB-internal fuses, together with a signature-verifying boot loader in DBB-internal mask ROM. As the root of the chain of trust is moving deeper into the hardware, it becomes more difficult for anyone to make software modifications to the DBB. Especially with tighter integration, where RAM and FLASH are no longer present as discrete components but part of a multi-chip-package, the number of options are becoming more limited. On the other hand, an ever more complex baseband software stack is opening up many more options for exploiting software vulnerabilities. Given the lack of a proper/modern operating system with privilege separation and virtual memory, such exploits immediately give away full access to all aspects of the respective DBB. \section{Personal rant on the closedness of the GSM industry} The GSM industry is one of the most closed areas of computing that I've encountered so far. It is very hard to get any hard technical information out of them. All they like to spread is high-level marketing information, but they're very reluctant when it comes down to hard technical facts on their products. If you want to build a phone, you need to buy a GSM chipset for your product. There are only very few companies that offer such chipsets. The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI (now MediaTek) and Freescale. The GSM handset products they sell are not generally available and distributed like other electronic component they manufacture. If you need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth chip, RFID reader ASIC, you simply approach the respective distributors and order them. You get your samples directly from Digikey. This is impossible for GSM (or other cellphone) chipsets. For some reason those chips are sold only to hand-picked manufacturers. If you want to qualify, you have to subscribe to at least six-digit annual purchasing quantities. And in order for them to believe you, you have to cough up a significant NRE (non-refundable engineering fee). This has been reported as high as a seven-digit US\$ amount and is to make sure that even if you end up buying less chips than you indicate, the chipset maker will still have your upfront NRE money and keep it. And if you buy your way into that select club of cellphone makers, what you get from the chipset maker is typically not all too impressive either. The documentation you get is incomplete, i.e. it alone would not enable you as a cellphone maker to make any use of the hardware, unless you license the software (drivers, GSM protocol stack, ...) from the chipset maker, too. On the software side, most of the technologically interesting bits (like the protocol stack) are provided as binary-only libraries, you only get source code to some parts of the systems, i.e. some hardware drivers that might need modification for your particular phone electrical design. That GSM protocol stack was not written by the chipset maker either. They simply license a stack from one of the estimated 4 or 5 organizations who have ever implemented a commercial GSM protocol stack. It is not like the GSM protocols were some kind of military secret. They are a published international standard, freely accessible for anyone. So why does everybody in that industry think that there is a need to be so secretive? Having spent a significant part of the last 6 years with reverse engineering of various aspects of mobile phones in order to understand them better and do write software tools for security analysis, I still don't understand this secrecy. All the various vendors do more or less the same. The fundamental architecture of a GSM baseband chip is the same, whether you buy it from TI, Infineon or from MediaTek. {\em They all cook with water}, like we Germans tend to say. The details like the particular DSP vendor or whether you use a traditional IF, zero-IF or low-IF analog baseband differ. But from whom do they want to hide it? If people like myself with a personal interest in the technical aspects of mobile phones can figure it out in a relatively short time, then I'm sure the competiton of those chipset makers can, too. In much less time, if they actually care. This closedness of the cellular industry is one of the reasons why there has been very little innovation in the baseband firmware throughout the last decades. Innovation can only happen by very few players. Source code bugs can only be found and fixed by very few developers at even fewer large corporations. No chance for a small start-up to innovate, like they can in the sphere of the internet. It is fundamentally also the reason why the traditional phone makers have been losing market share to newcomers to the mobile sphere like Apple with its iPhone or Google with its Android platform. Those innovations really only happened on the application processor on high-end smartphones. The closed GSM baseband processor had to be accompanied by an independent application processor running a real operating system, with real processes, memory management, shared libraries, memory protection, virtual memory spaces, user-installable applications, etc. They still don't happen on the baseband processor, which is as closed as it was 15 years ago. \end{document} --3V7upXqbjpZ4EhLz-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: patience" is a really good guess. Let me explain how this works: In Shenzhen there is a huge electronics area. Thousands of shops and companies, hundreds of thousands of people working and trading there. I have a small collection of pictures so you get the idea... http://en.qi-hardware.com/wiki/Shenzhen_markets (this stretches over an area of at least 1x1 km, with dozens of 8+ level buildings, some higher like the 70-floor office tower :-)) Basically you can walk up to any PCB shop (there are at least 50 I would say). I went to one I used before with 2 Sciphone Dream G2 boards, and they accepted the job for 600 RMB (=ca. 90 USD). I got the pictures 4 days later. I got them as .bmp files, then I did some post-processing to make nice horizontally aligned, contrast-enriched PNGs out of them, and a big PDF too to easily flip through the layers (PDF readers tend to be quite powerful and efficient in scaling and flipping, so this seems to work well). I am not an electronics guy, so I need feedback to do this kind of work better in the future. For example, I don't know the exact names of the layers. Can someone who knows what they are add subtitles to the wiki? Copper layer, ground layer, via, whatever? (I just don't know...) Or reply here and I'll annotate the wiki. Anything else I should do to make this better next time? This is all background info I have, one day I will convince them to let me take some pictures of the actual work :-) Wolfgang From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: velopment, so our drivers could be more portable and we'll see if they'll b= e also aplicable for MT6516. BR, Marcin= From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: main_simtrace.bin, using dfu-util from http://dfu-util.gnumonks.org -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: what do you think? From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: all the powerfull eye-candy apps. But that takes processing power. So SoC provider would separate processing on two cores, puting stack on the other core. Since this other core do not demand any application except PS, you would like to run some nice lightweight OS like eCos, or similar that have good RT performances to assure timing requirements for L1 and inter-CPU communication. If there would be satisfying performance on one core, there would certanly be interest to save money by rejecting the other. And to figure out how to separate closed source, how to keep legacy RTOS and RT apps, etc... And since more powerful cores are appearing, L4 comes into play on big doors (not to mention that it's the worlds first formally verified kernel). BR, Drasko From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: > Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation > for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a > simplistic BTS), and I have started to split that code out into a separate > repository at http://cgit.osmocom.org/cgit/osmo-bts/ > > This code should eventually be used with the OpenBTS, and potentially other > BTS types, too. That's cool!!!! > >> With that approach the 'GSM-um' interface would be a very simplified >> module of the overall system and osmocom would completely replace >> OpenBTS all-in-one project. > > This is where I don't get you. All that needs to be removed is the L3-to-SIP > bridge. It doesn't make the vast majority of OpenBTS code disappear, > and it does not render that latter part useless. A full-blown GSM network with > all its components brings a lot of complexity. The stand-alone OpenBTS is > much more simple. And why would you want all the complexity if you don't > need to interoperate with legacy GSM? Well, because the the osmocom-integrated version will be, before or later, more full-featured than OpenBTS standalone. Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable only jointly with Osmocom integration but not by the opensource OpenBTS standalone version. Obviously the community will then use the OpenBTS/OpenBSC integration that would reach more features than just OpenBTS in the opensource edition. That means that in few times only the "integrated code" will works better, because it will attract more user and will start getting used in "production environment". So the integrated code will grow while the "OpenBTS commercial code" will leave behind with less features and more buggy code (because less used). That's why i just think that the destinity of OpenBTS is to integrate (directly or just some piece) with OpenBSC, but doing that it will loose several important value of the "OpenBTS commercial edition" and people will start using what can be used for free instead of paying. That's what usually happen within the opensource environment, before or later. It could reasonably happen also with that opensource gsm environment. My comments was just consideration on this to stimulate the considerations on this by the various project players. I am just an opensource advocacy troll that like telephony stuff and perceive very valuable the achievement of the hacking community in opening a closed technology like GSM. Osmocom and it's possible future changes to the market of GSM technologies could be defined as "the WikiLeaks of the GSM Industry" :-) -naif p.s. i have no commercial interests of any kind in that stuff From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: Sure, it would be a nice addition, but it's not something that I consider extremely important. With regard to 'near future': I would say that in something like six months the osmo-bts (BTS-side A-bis) code will have matured, and is ready for an relaatively painless integration with OpenBTS. I personally think the USRP hardware cost is still way too high, and I would rather want to work on something that puts the financial entrance barrier to private BTS ownership much lower. Most of the people using OpenBSC today either use it commercially (and can afford the nanoBTS units), or they use it private and either with a very cheap second hand nanoBTS, or with a inexpensive BS-11. The recent work on supporting the RBS2308 that can be found for < 1000 USD goes into the same direction. I think whatever hardware will be affordable to hackers will see OpenBSC support - just as well as any hardware where we have a commercial customer will get OpenBSC support. > > This is where I don't get you. All that needs to be removed is the L3-to-SIP > > bridge. It doesn't make the vast majority of OpenBTS code disappear, > > and it does not render that latter part useless. A full-blown GSM network with > > all its components brings a lot of complexity. The stand-alone OpenBTS is > > much more simple. And why would you want all the complexity if you don't > > need to interoperate with legacy GSM? > > Well, because the the osmocom-integrated version will be, before or > later, more full-featured than OpenBTS standalone. > > Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable > only jointly with Osmocom integration but not by the opensource OpenBTS > standalone version. If you use the USRP hardware (or any other SDR hardware), you cannot use GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. As for hand-over, you may be right, but I don't know the OpenBTS plans here. Multi-ARFCN: This is an aspect of the radio-modem. So again, on the same hardware any OpenBTS/OpenBSC integration will not change this. > Obviously the community will then use the OpenBTS/OpenBSC integration > that would reach more features than just OpenBTS in the opensource edition. well, but you loose the important 'simplicity' feature. Right now I doubt there are that many people in our community who understand OpenBSC and the GSM/GPRS network architecture enough to deploy a network (like the burning man or CCC event networks) with it. We have close to zero documentation, and unless you know GSM protocol details, you are lost. VoIP is much better understood in the FOSS and Internet community! > So the integrated code will grow while the "OpenBTS commercial code" > will leave behind with less features and more buggy code (because less > used). you are making assumptions here. Do you have evidence or at least some other indication that bug fixes are not being propagated from the commercial to the free version? > Osmocom and it's possible future changes to the market of GSM > technologies could be defined as "the WikiLeaks of the GSM Industry" :-) I think this is a very bad comparison. We do not leak any proprietary/secret information. We just break the ignorance of the Free Software community to ever implement any of those openly-specified protocols. Not different from Free Software entering any other area of technology. And while we're doing that, we of course also like to challenge the ridiculous claims of hundred-man-year efforts that allegedly went into some proprietary GSM protocol stack implementations, which are often claimed by the existing carrier equipment industry. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: OsmocomBB> show ms MS '1' is up, service is limited (pending) =20 IMEI: 000000000000000 =20 IMEISV: 0000000000000000 =20 IMEI generation: fixed =20 automatic network selection state: A3 trying PLMN cell selection state: C4 normal cell re-selection radio ressource layer state: idle =20 mobility management layer state: MM idle, attempting to update OsmocomBB> show subscriber =20 Mobile Subscriber of MS '1': =20 IMSI: 234------------ =20 ICCID: 894----------- =20 Status: U2_NOT_UPDATED IMSI detached LAI: invalid =20 Registered PLMN: MCC 234 MNC 30 (Guernsey, T-Mobile) =20 Access barred cells: no =20 Access classes: C5 =20 List of preferred PLMNs: =20 MCC |MNC =20 -------+------- =20 214 |07 (Spain, movistar) =20 208 |01 (France, Orange) =20 310 |260 (United States of America, T-Mobile USA) 310 |170 (United States of America, Cingular Wireless) 262 |01 (Germany, T-Mobile) =20 272 |03 (Ireland, Meteor) =20 222 |01 (Italy, TIM) =20 204 |16 (Netherlands, T-Mobile) =20 268 |06 (Portugal, TMN) =20 206 |10 (Belgium, Mobistar) =20 505 |02 (Australia, Optus) =20 228 |03 (Switzerland, Orange) =20 232 |03 (Austria, T-Mobile) =20 520 |01 (Thailand, AIS) =20 230 |01 (Czech Republic, T-Mobile) =20 338 |180 (Jamaica, LIME (formerly known as Cable &=20 Wireless)) 655 |10 (South Africa,=20 MTN) =20 286 |02 (Turkey,=20 Vodafone) =20 602 |02 (Egypt,=20 Vodafone) =20 454 |00 (Hong Kong, 1O1O and=20 One2Free) =20 216 |30 (Hungary, Westel=20 900) =20 250 |01 (Russian Federation,=20 MTS) =20 334 |030 (Mexico,=20 030) =20 425 |02 (Israel,=20 Cellcom) =20 240 |01 (Sweden,=20 Telia) =20 202 |01 (Greece, Cosmote) 639 |02 (Kenya, Safaricom) 260 |02 (Poland, Era) 231 |02 (Slovakia, T-Mobile) 219 |01 (Croatia, T-Mobile) 413 |01 (Sri Lanka, Mobitel) 242 |02 (Norway, NetCom) 238 |30 (Denmark, Telia) 278 |01 (Malta, Vodafone) 604 |01 (Morocco, IAM) 617 |10 (Mauritius, Emtel) 419 |02 (Kuwait, zain KW) 244 |91 (Finland, Sonera) 284 |05 (Bulgaria, GLOBUL) 648 |03 (Zimbabwe, Telecel) 204 |20 (Netherlands, Orange Nederland) 228 |01 (Switzerland, Swisscom) 230 |03 (Czech Republic, Vodafone) 214 |01 (Spain, Vodafone) 202 |05 (Greece, Vodafone) 262 |02 (Germany, Vodafone) 222 |10 (Italy, Vodafone) 268 |01 (Portugal, Vodafone) 208 |10 (France, SFR) 342 |600 (Barbados, Cable & Wireless (Barbados) Ltd.) List of forbidden PLMNs: MCC |MNC |cause -------+-------+------- 234 |33 |#0 (Guernsey, Orange) 234 |15 |#0 (Guernsey, Vodafone) 234 |10 |#0 (Guernsey, O2) 234 |13 |#0 (Guernsey, 13) from the mobile application I get: =1B[0;35m<000e> sim.c:1206 init SIM client =1B[0;m=1B[1;33m<0005> gsm48_cc.c:61 init Call Control =1B[0;m=1B[1;34m<0001> gsm48_rr.c:4944 init Radio Ressource process =1B[0;m=1B[1;32m<0004> gsm48_mm.c:1220 init Mobility Management process =1B[0;m=1B[1;32m<0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because = no SIM. =1B[0;m=1B[32m<0002> gsm322.c:3472 init PLMN process =1B[0;m=1B[34m<0003> gsm322.c:3473 init Cell Selection process =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D10 = Guernsey,=20 O2) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D30 = Guernsey,=20 T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D13 = Guernsey,=20 13) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D15 = Guernsey,=20 Vodafone) =1B[0;m=1B[34m<0003> gsm322.c:3523 Read stored BA list (mcc=3D234 mnc=3D33 = Guernsey,=20 Orange) =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x2fe2 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:697 go MF =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x3f00) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 1a) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D26) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D26 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x2fe2) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D10) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D10 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:229 received ICCID 8944301471319463636 = from=20 SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f07 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:706 requested path is longer, go child DFgsm =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x7f20) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 1a) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D26) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D26 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f07) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D9) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D9 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:259 received IMSI 234------------- from= SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f7e =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f7e) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D11) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D11 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:295 received LOCI from SIM (mcc=3D234 m= nc=3D30=20 lac=3D0x0886 U3) =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f40 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f40) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x94 sw2=3D0x= 04) =1B[0;m=1B[0;35m<000e> sim.c:952 command failed =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D1) =1B[0;m=1B[1;32m<0004> subscriber.c:608 SIM reading failed, ignoring! =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f20 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f20) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D9) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D9 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:342 received KEY from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f30 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f30) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D153) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D153 sw1=3D0x90 sw2=3D= 0x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D214 m= nc=3D07)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D208 m= nc=3D01)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D310 m= nc=3D260)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D310 m= nc=3D170)=20 from SIM ...... =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D208 m= nc=3D10)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:380 received PLMN selector (mcc=3D342 m= nc=3D600)=20 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f31 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f31) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D1) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D1 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:401 received HPPLMN 5 (30 mins) from SI= M =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f46 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f46) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D17) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D17 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:635 SIM reading failed, file invalid =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f78 =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f78) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D2) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D2 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:442 received ACC 0020 from SIM =1B[0;m=1B[1;32m<0004> subscriber.c:556 Requesting SIM file 0x6f7b =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY=20 (handle=3D00000004) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f7b) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:277 READ BINARY (offset=3D0 len=3D12) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xb0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D12 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[1;32m<0004> subscriber.c:518 (ms 1) Done reading SIM card=20 (IMSI=3D234308339737861 Guernsey, T-Mobile) =1B[0;m=1B[1;32m<0004> subscriber.c:530 -> SIM card registered to 234 30=20 (Guernsey, T-Mobile) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:4147 (ms 1) Received 'MMR_REG_REQ' event =1B[0;m=1B[32m<0002> gsm322.c:3099 (ms 1) Event 'EVENT_SIM_INSERT' for auto= matic=20 PLMN selection in state 'A0 null' =1B[0;m=1B[1;37m<000d> gsm322.c:1072 Start search of last registered PLMN (= mcc=3D234=20 mnc=3D30 Guernsey, T-Mobile) =1B[0;m=1B[32m<0002> gsm322.c:1076 Use RPLMN (mcc=3D234 mnc=3D30 Guernsey,= T-Mobile) =1B[0;m=1B[32m<0002> gsm322.c:512 new state 'A0 null' -> 'A1 trying RPLMN' =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_NEW_PLMN' for Cell= =20 selection in state 'C0 null' =1B[0;m=1B[1;37m<000d> gsm322.c:2934 Selecting network (mcc=3D234 mnc=3D30 = Guernsey,=20 T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:2940 Start stored cell selection. =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C0 null' -> 'C2 stored cell=20 selection' =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 573 rxlev -98 (1= 2)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 573 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 573 rxlev -94 (1= 6)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 577 rxlev -101 (= 9)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 577 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 577 rxlev -97 (1= 3)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 579 rxlev -96 (1= 4)) ...... =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 713 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 713 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 715 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 715 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 715 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 717 rxlev -98 (1= 2)) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 717 twice. Over= writing=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 717 rxlev -95 (1= 5)) =1B[0;m=1B[34m<0003> gsm322.c:2349 Found 31 frequencies. =1B[0;m=1B[34m<0003> gsm322.c:258 Sync to ARFCN=3D581 rxlev=3D-91 (No sysin= fo yet,=20 ccch mode NONE) =1B[0;m=1B[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=3D581, snr=3D11,= BSIC=3D37) =1B[0;m=1B[1;34m<0001> gsm322.c:2461 using DSC of 90 =1B[0;m=1B[34m<0003> gsm48_rr.c:4548 Channel provides data. =1B[0;m=1B[1;34m<0001> sysinfo.c:652 Ignoring SYSTEM INFORMATION 4 until SI= 1 is=20 received. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1798 New SYSTEM INFORMATION 4 (mcc 000 mn= c 000=20 lac 0x0000) =1B[0;m=1B[1;34m<0001> sysinfo.c:540 Now decoding previously received SYSTE= M=20 INFORMATION 4 =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1643 New SYSTEM INFORMATION 1 =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:1672 New SYSTEM INFORMATION 2 =1B[0;m=1B[34m<0003> gsm322.c:2054 New BA list (mcc=3D234 mnc=3D30 Guernse= y, T- Mobile). =1B[0;m=1B[1;34m<0001> sysinfo.c:633 New SYSTEM INFORMATION 3 (mcc 234 mnc = 30 lac=20 0x0376) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1764 Changing CCCH_MODE to 1 =1B[0;m=1B[34m<0003> gsm322.c:1598 Cell frequency 581: Cell found, (rxlev= =3D-91=20 mcc=3D234 mnc=3D30 lac=3D0376 Guernsey, T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:1608 Cell frequency 581 selected. =1B[0;m=1B[34m<0003> gsm322.c:1923 Tune to frequency 581. =1B[0;m=1B[34m<0003> gsm322.c:252 Sync to ARFCN=3D581 rxlev=3D-91 (Sysinfo,= ccch mode=20 NON-COMB) =1B[0;m=1B[34m<0003> gsm322.c:1964 Cell available. =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_CELL_FOUND' for Cell= =20 selection in state 'C2 stored cell selection' =1B[0;m=1B[1;37m<000d> gsm322.c:2744 Camping normally on cell (arfcn=3D581 = mcc=3D234=20 mnc=3D30 Guernsey, T-Mobile) =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C2 stored cell selection' -> '= C3=20 camped normally' =1B[0;m=1B[1;32m<0004> gsm48_mm.c:4079 (ms 1) Received 'MM_EVENT_CELL_SELEC= TED'=20 event in state MM IDLE, PLMN search =1B[0;m=1B[1;32m<0004> gsm48_mm.c:882 new MM IDLE state PLMN search -> loca= tion=20 updating needed =1B[0;m=1B[1;32m<0004> gsm48_mm.c:882 new MM IDLE state location updating n= eeded - > attempting to update =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2138 Do normal Loc. upd. =1B[0;m=1B[1;37m<000d> gsm48_mm.c:2067 Perform location update (MCC 234, MN= C 30=20 LAC 0x0376) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2189 LOCATION UPDATING REQUEST =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2211 using LAI (mcc 234 mnc 30 lac 0x088= 6) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2225 using IMSI 234---------------- =1B[0;m=1B[1;32m<0004> gsm48_mm.c:887 new state MM IDLE, attempting to upda= te ->=20 wait for RR connection (location updating) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:4911 (ms 1) Message 'RR_EST_REQ' received= in=20 state idle =1B[0;m=1B[1;37m<000d> gsm48_rr.c:1181 Establish radio link due to mobility= =20 management request =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell= =20 selection in state 'C3 camped normally' =1B[0;m=1B[34m<0003> gsm322.c:2959 Going to camping frequency 581. =1B[0;m=1B[34m<0003> gsm322.c:252 Sync to ARFCN=3D581 rxlev=3D-91 (Sysinfo,= ccch mode=20 NON-COMB) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:363 new state idle -> connection pending =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1320 CHANNEL REQUEST: 00 (Location Update= with=20 NECI) =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[34m<0003> gsm322.c:2475 Channel sync error. =1B[0;m=1B[34m<0003> gsm322.c:2508 Loss of CCCH. =1B[0;m=1B[34m<0003> gsm322.c:2528 Loss of SACCH, Trigger RR abort. =1B[0;m=1B[1;37m<000d> gsm48_rr.c:2700 Radio link lost signal =1B[0;m=1B[1;34m<0001> gsm48_rr.c:2707 LOS during RACH request =1B[0;m=1B[1;34m<0001> gsm48_rr.c:363 new state connection pending -> idle =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_RET_IDLE' for Cell= =20 selection in state 'C3 camped normally' =1B[0;m=1B[34m<0003> gsm322.c:2890 Selecting frequency 581. after LOC.UPD. =1B[0;m=1B[34m<0003> gsm322.c:252 Sync to ARFCN=3D581 rxlev=3D-91 (Sysinfo,= ccch mode=20 NON-COMB) =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C3 cam= ped=20 normally' =1B[0;m=1B[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR= in=20 state wait for RR connection (location updating) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2589 RR link released after loc. upd. =1B[0;m=1B[1;37m<000d> gsm48_mm.c:2533 Location update failed =1B[0;m=1B[1;32m<0004> subscriber.c:1014 (ms 1) new state U3_ROAMING_NA ->= =20 U2_NOT_UPDATED =1B[0;m=1B[1;32m<0004> subscriber.c:795 Updating LOCI on SIM =1B[0;m=1B[1;37m<000d> gsm48_mm.c:2572 Try location update later =1B[0;m=1B[1;32m<0004> gsm48_mm.c:4083 (ms 1) Received 'MM_EVENT_CELL_SELEC= TED'=20 event in state wait for RR connection (location updating) =1B[0;m=1B[1;32m<0004> gsm48_mm.c:1021 Starting T3211 after RR release. =1B[0;m=1B[1;32m<0004> gsm48_mm.c:391 starting T3211 (loc. upd. retry delay= ) with=20 15.0 seconds =1B[0;m=1B[1;32m<0004> gsm48_mm.c:1070 We are camping normally as returning= to MM=20 IDLE =1B[0;m=1B[1;32m<0004> gsm48_mm.c:892 new state wait for RR connection (loc= ation=20 updating) -> MM IDLE, location updating needed =1B[0;m=1B[1;32m<0004> gsm48_mm.c:882 new MM IDLE state location updating n= eeded - > attempting to update =1B[0;m=1B[1;32m<0004> gsm48_mm.c:2083 Loc. upd. already pending. =1B[0;m=1B[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY=20 (handle=3D00000005) =1B[0;m=1B[0;35m<000e> sim.c:241 SELECT (file=3D0x6f7e) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x9f sw2=3D0x= 0f) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:571 GET RESPONSE (len=3D15) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D15 sw1=3D0x90 sw2=3D0= x00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:294 UPDATE BINARY (offset=3D0 len=3D11) =1B[0;m=1B[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) =1B[0;m=1B[0;35m<000e> sim.c:876 received APDU (len=3D0 sw1=3D0x90 sw2=3D0x= 00) =1B[0;m=1B[0;35m<000e> sim.c:949 command successfull =1B[0;m=1B[0;35m<000e> sim.c:151 sending result to callback function (type= =3D0) =1B[0;m=1B[34m<0003> gsm322.c:2475 Channel sync error. =1B[0;m=1B[34m<0003> gsm322.c:2508 Loss of CCCH. =1B[0;m=1B[34m<0003> gsm322.c:2516 Loss of CCCH, Trigger re-selection. =1B[0;m=1B[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_CELL_RESEL' for Cell= =20 selection in state 'C3 camped normally' =1B[0;m=1B[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C4 nor= mal=20 cell re-selection' =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 0 rxlev -98 (12)= ) =1B[0;m=1B[34m<0003> gsm322.c:2405 Getting PM for frequency 0 twice. Overwr= iting=20 the first! Please fix prim_pm.c =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 0 rxlev -97 (13)= ) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1 rxlev -95 (15)= ) ...... =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1019 rxlev -95 (= 15)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1020 rxlev -95 (= 15)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1021 rxlev -95 (= 15)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1022 rxlev -96 (= 14)) =1B[0;m=1B[34m<0003> gsm322.c:2416 Found signal (frequency 1023 rxlev -96 (= 14)) =1B[0;m=1B[34m<0003> gsm322.c:2349 Found 568 frequencies. =1B[0;m=1B[34m<0003> gsm322.c:258 Sync to ARFCN=3D102 rxlev=3D-68 (No sysin= fo yet,=20 ccch mode NONE) =1B[0;m=1B[34m<0003> gsm322.c:2475 Channel sync error. =1B[0;m=1B[34m<0003> gsm322.c:2218 Cell selection failed, sync timeout. =1B[0;m=1B[34m<0003> gsm322.c:258 Sync to ARFCN=3D53 rxlev=3D-72 (No sysinf= o yet, ccch=20 mode NONE) =1B[0;m=1B[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=3D53, snr=3D15, = BSIC=3D52) =1B[0;m=1B[1;34m<0001> gsm322.c:2461 using DSC of 90 =1B[0;m=1B[34m<0003> gsm48_rr.c:4548 Channel provides data. =1B[0;m=1B[1;34m<0001> sysinfo.c:633 New SYSTEM INFORMATION 3 (mcc 234 mnc = 10 lac=20 0xc44b) =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1764 Changing CCCH_MODE to 1 =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> sysinfo.c:652 Ignoring SYSTEM INFORMATION 4 until SI 1 is= =20 received. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:1798 New SYSTEM INFORMATION 4 (mcc 234 mn= c 10=20 lac 0xc44b) =1B[0;mwriting msgb to gsmtap fd: Connection refused writing msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;m=1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused =1B[1;34m<0001> gsm48_rr.c:2006 PAGING ignored, we are not camping. =1B[0;mwriting msgb to gsmtap fd: Connection refused From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: * it tries to stay as close to POSIX and other Unix APIs as possible * you can actually have executable programs in the file system * it contains a small interactive shell * the changelog is verbose and releases are frequent * there's a test suite * there are already ports to other ARM7TDMI microcontrollers * there is a small UI framework and the notion of drivers for SPI- attached LCDs (with 1/2/4 bpp) * it has tasks and threads, pre-emptive and with priorities * it has posix message queues, which we could use for passing around primitives between elements in the stack * it can be used on Unix-like and Windows/Cygwin host OS * it has its own scripts to generate toolchains, which means we could possibly standardize on one of those toolchains Of course, not everything is perfect * there seems to be no writeable FS we can put in NOR flash * it has no scripting language integration (like lua) yet * i didn't find any memory allocator optimized for pools of objects of the same size (like 'struct msgb' or the like). Something with an API [not implementation!] of the SLAB/SLUB in Linux would probably be a good start. I've done some example compile runs for arm7, including the shell and the graphics support (nx example). I end up with an object code size of something like 70 kilobytes, which is pretty good! So unless anyone raises major objections, I think we should move ahead with Nuttx. Who is interested in working on the calypso port? Let's use this list for coordinating the effort. As for where to put the code: I already have a git-svn clone of Nuttx, and will push that to a soon-to-be-created nuttx.git repository on git.osmocom.org. The core calypso support (irq, uart, spi, etc.) should all go in that tree. Meanwhile we will figure out how it would be possibel to keep the gsm related 'application' code out-of-tree from the nuttx code base. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: ISM868 bands that are located adjacent to the GSM 850/900 frequency allocations. My initial investigations and enquiries indicate that this should be possible by creative programming of the baseband processor in many models of phones. The trick, as I suspect you well know, is the difficulty in getting the information and tools required to reprogram these radios. I am now in a position to potentially fund further work on this. So, as the open-source group with the most experience reprogramming baseband radios, what is the feasibility of creating a proof-of-concept using the types of phones you already work with to send and receive arbitrary data packets without reliance on a cell tower (even for time synchronisation)? I know there are a lot of constraints and problems, but I am most interested in creative solutions that can get us to a working prototype, however crude, that can be used to demonstrate the feasibility of what I am proposing. If this discussion is off-topic here, I am happy to hold the conversation at the serval-project-developers google group, but I am equally comfortable with it continuing here. Thanks in advance, Paul Gardner-Stephen. Shuttleworth Telecommunications Fellow at Flinders University. From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: ISM868 bands that are located adjacent to the GSM 850/900 frequency
allocations.

My initial investigations and enquiries indicate that this should be
possible by creative programming of the baseband processor in many
models of phones. =A0The trick, as I suspect you well know, is the
difficulty in getting the information and tools required to reprogram
these radios.

I am now in a position to potentially fund further work on this.

So, as the open-source group with the most experience reprogramming
baseband radios, what is the feasibility of creating a
proof-of-concept using the types of phones you already work with to
send and receive arbitrary data packets without reliance on a cell
tower (even for time synchronisation)?

I know there are a lot of constraints and problems, but I am most
interested in creative solutions that can get us to a working
prototype, however crude, that can be used to demonstrate the
feasibility of what I am proposing.

If this discussion is off-topic here, I am happy to hold the
conversation at the serval-project-developers google group, but I am
equally comfortable with it continuing here.

Thanks in advance,
Paul Gardner-Stephen.
Shuttleworth Telecommunications Fellow at Flinders University.


--0016367faa93c4a56b04abdc0ca5-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: ISM868 bands that are located adjacent to the GSM 850/900 frequency
allocations.

My initial investigations and enquiries indicate that this should be
possible by creative programming of the baseband processor in many
models of phones. =A0The trick, as I suspect you well know, is the
difficulty in getting the information and tools required to reprogram
these radios.

I am now in a position to potentially fund further work on this.

So, as the open-source group with the most experience reprogramming
baseband radios, what is the feasibility of creating a
proof-of-concept using the types of phones you already work with to
send and receive arbitrary data packets without reliance on a cell
tower (even for time synchronisation)?

I know there are a lot of constraints and problems, but I am most
interested in creative solutions that can get us to a working
prototype, however crude, that can be used to demonstrate the
feasibility of what I am proposing.

If this discussion is off-topic here, I am happy to hold the
conversation at the serval-project-developers google group, but I am
equally comfortable with it continuing here.

Thanks in advance,
Paul Gardner-Stephen.
Shuttleworth Telecommunications Fellow at Flinders University.


--0016367b5dfaa9e5ed04abe063a0-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: osmo_auth_load() osmo_auth_supported() osmo_auth_gen_vec() osmo_auth_gen_vec_auts() osmo_auth_alg_name() osmo_auth_alg_parse() You can check the libosmocore/utils/osmo-auc-gen.c example on how they are used to generate authentication truplets or quintuples. OpenBSC predates this generic API and should be updated. Once again, contributions are welcome. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: keep doing the same style. Good food makes a brain work better. > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. Berlin is perfect. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: Wireshark. Tracing the code shows that it is waiting for some input which never comes. The only way to get things going again is to stop and restart ccch_scan. The issue has been briefly raised in two earlier emails from Altaf and Joshua with a reply from Sylvain which I have copied below. Although Sylvain explains the meaning of the error, no solution has been discussed so far as far as can find. Studying the code in various apps to see how they handle S_L1CTL_FBSB_ERR, it seems the only way to get it going is to restart the sync to ARFCN. I do it by copying code from app_cbch_sniff.c and inserting the following case option in signal_cb() in app_ccch_scan.c: case S_L1CTL_FBSB_ERR: > ms = ((osmobb_fbsb_res *) signal_data)->ms; > return l1ctl_tx_fbsb_req(ms, ms->test_arfcn, > L1CTL_FBSB_F_FB01SB, 100, 0, CCCH_MODE_COMBINED, > dbm2rxlev(-85)); Frankly I do not know what exactly l1ctl_tx_fbsb_req does, but it seems to work pretty well. Except *very rarely* I find that after processing this resync, ccch_scan gives repeated data corruptions messages like: <000c> l1ctl.c:238 Dropping frame with 78 bit errors repeating endlessly! Can Holger or Harald who have written ccch_scan please confirm if this is the correct way to fix the problem or if there is better solution? Can you please also insert the update in the ccch_scan code in the burst_ind branch so that others can benefit? Thanks in advance! B. Related earlier emails below: ========================== From: Altaf gmail.com> Subject: Re: Osmocom-bb Making a call Date: 2012-05-24 16:49:14 GMT (31 weeks, 4 days, 18 hours and 16 minutes ago) When I run the Layer23(ccch_scan) application it gives me the following output on the terminal.... Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <000c> l1ctl.c:114 FBSB RESP: result=255 What does it mean.. Can some one help me at this point.. -- *What does FBSB RESP: result=255 mean?* *Sylvain Munaut* 246tnt at gmail.com *Thu Apr 26 01:45:42 CEST 2012* Hi, >* Running ccch_scan or bcch_scan in the sylvain/burst_ind branch, I keep*>* getting this error:* bcch_scan doesn't make sense on burst_ind. Only ccch_scan is meant to do anything useful, all the other apps may do random things becaue they're not meant for use in burst_ind. >* <000c> l1ctl.c:114 FBSB RESP: result=255*>**>* I tried checking the code, but I can't quite figure out what's going on. It*>* looks like 255 is an error code, but I don't know where to go from there.* It just means failure to sync ... Most likely the ARFCN you gave doesn't carry a valid C0. Note that it's only tested on 900/1800. US band support is not tested and probably not functional especially in burst_ind. Fixing it is left as an exercise to the reader ... --f46d044468e32d3f9604d2391d02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
When I run ccch_scan on a regular network, every once in a while, at r= andom I find the app stops sniffing with the error:
<000c> l1ctl.c:291 BURST IND: @(1428545 =3D 1077/01/35) (-105 dBm, SN= R =A0 3, SACCH)
<000c> l1ctl.c:114 FBSB RESP: result=3D255

At the same time Osmocon gives a message lik= e the following:
=3D> DSP reports FB in bit that is 1031487569 bits= in the future?!?
Synchronize_TDMA
LOST 2313!

The pr= oblems seems therefore to emerge from some corruption of data in reception = which causes l1ctl.c to dispatch the=A0S_L1CTL_FBSB_ERR=A0signal.

From this point on ccch_scan ceases to send any further= messages to Wireshark. Tracing the code shows that it is waiting for some = input which never comes. The only way to get things going again is to stop = and restart ccch_scan.

The issue has been briefly raised in two earlier emails= from Altaf and =A0Joshua with a reply from Sylvain which I have copied bel= ow. Although Sylvain explains the meaning of the error, no solution has bee= n discussed so far as far as can find.

Studying the code in various apps to see how they handl= e=A0S_L1CTL_FBS= B_ERR, it seems the only way to get it going is to restart the sync = to ARFCN. I do it by copying code from app_cbch_sniff.c and inserting the f= ollowing case option in=A0signal_cb() in app_ccch_scan.c:

= case S_L1C= TL_FBSB_ERR: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=A0
ms =3D ((= osmobb_fbsb_res *) signal_data)->ms;
return l1ctl_tx_fbsb_req(ms, ms->test_= arfcn,
L1CTL_FB= SB_F_FB01SB, 100, 0, CCCH_MODE_COMBINED,
dbm2rxlev(-85));

Frankly I do not know what exactly=A0l1ctl_tx_fbsb_req does, but it = seems to work pretty well. Except *very rarely* I find that after processin= g this resync, ccch_scan gives repeated data corruptions messages like:

<000c> l1ctl.c:238 Dropping fram= e with 78 bit errors

repeating endlessly!

Can= Holger or Harald who have written ccch_scan please confirm if this is the = correct way to fix the problem or if there is better solution? Can you plea= se also insert the update in the ccch_scan code in the burst_ind branch so = that others can benefit?

Thanks in advance!

B.

Related earlier emails below:
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
From: Altaf <altaf329 <at> gmail.com<= /a>>
Subject:=A0Re: Osmocom-bb Making a call
Date: 2012-05-24 16:49:14 GMT (31 weeks, 4 days, 18 hours and 16 minutes ag= o)
When I run the Layer23(ccch_scan) application it gives me the =
following
output on the terminal....

Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
<000c> l1ctl.c:114 FBSB RESP: result=3D255

What does it mean.. Can some one help me at this point..

--
W=
hat does FBSB RESP: result=3D255 mean?
Sylvain Munaut=A0246tnt at g=
mail.com=A0

Thu Apr 26 01:45:42 CEST 2012
Hi,

> Running ccch_scan or bcch_scan in the sylvain/burst_ind branch, I k=
eep
> getting this error:

bcch_scan doesn't make sense on burst_ind. Only ccch_scan is meant to
do anything useful, all the other apps may do random things becaue
they're not meant for use in burst_ind.

> <000c> l1ctl.c:114 FBSB RESP: result=3D255
>
> I tried checking the code, but I can't quite figure out wha=
t's going on. =A0It
> looks like 255 is an error code, but I don't know where to =
go from there.

It just means failure to sync ...

Most likely the ARFCN you gave doesn't carry a valid C0.

Note that it's only tested on 900/1800. US band support is not tested
and probably not functional especially in burst_ind. Fixing it is left
as an exercise to the reader ...

--f46d044468e32d3f9604d2391d02-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: other but rather completely separate. And again from the spec, should you expect one or the other on a channel, you must ignore any packets with the wrong LPD. So AFAIK on a CBCH channel if you ever get a LPD=00 it should be ignored and not fed to a LAPDm processor. Same thing for a BTS side LAPDm instance if it receives a LPD=01 it should be ignored. From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: fed to LAPDm at all. So when you get a L2 packet from L1, instead of blindly feeding it to LAPDm, you should check a LPD handler table to know who to feed it to, and for normal channels there would only be handler for LAPDm and for CBCH channel there would be no LAPDm handler and only a LPD=01 handler. > In the future, we can also add the BTS-side implementation. I don't > think they can share much code, If they can't share code, then, I would make sure to mark the method to be 'ms' side so as to keep the namespace clear. Also, I would stick to the convention we used for sms and name it something like gsm412_ms_entity (and same for the methods) > but it might make sense to have both in the same place. That's not really the policy we used so far. Only shared code goes to libosmo-xxx If it ever comes a time where we need it in another project, it'll still be time to move it there then. > I can spin a patch series directly on top of osmocom-bb, but the > testcases will probably not make it. Why ? layer23 is auto-tools based as well, copying the test suite stuff from libosmocore shouldn't be too hard. Cheers, Sylvain From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: TDI - TP8 TCK - TP17 TDO - TP6 TMS - TP18 Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and 18. I can't seem to find TP6 or TP8 anywhere on the schematic. -Craig --344044665-458139408-1380812233=:84280 Content-Type: text/html; charset=us-ascii
I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway.

Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?

From what I can gather from the schematics:
TDI - TP8
TCK - TP17
TDO - TP6
TMS - TP18

Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and 18.

I can't seem to find TP6 or TP8 anywhere on the schematic.

-Craig

--344044665-458139408-1380812233=:84280-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: TDI - TP8 TCK - TP17 TDO - TP16 TMS - TP18 Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and 18. I can't seem to find TP6 or TP8 anywhere on the schematic. -Craig ---1562933420-544822754-1380899330=:47346 Content-Type: text/html; charset=us-ascii
I cracked open the shield on my C139 and didn't see the TPs I expected from the schematic. I thought maybe the angle of the photo on osmocom hid the TPs but it really didn't.

I'll try my C115 instead since that is more clear and accessible. Flashing hello_world on my C115 seemed to fail in a similar fashion as it does on my C139 so maybe the same issue exists there.

I was wrong too... it was TP16 not TP6, so I found TP16 but still haven't located TP8 on the C139 schematic.

-Craig


From: Craig Comstock <craig_comstock at yahoo.com>
To: "baseband-devel at lists.osmocom.org" <baseband-devel at lists.osmocom.org>
Sent: Thursday, October 3, 2013 9:57 AM
Subject: c139/c140 jtag anyone?

I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway.

Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?

From what I can gather from the schematics:
TDI - TP8
TCK - TP17
TDO - TP16
TMS - TP18

Looking at the board from the battery compartment side with the top of the phone pointing North/Up I see at least TP17 is near the right-hand bank of test points visible from the battery compartment. From left-to-right there I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two of the TPs I need: 17 and 18.

I can't seem to find TP6 or TP8 anywhere on the schematic.

-Craig



---1562933420-544822754-1380899330=:47346-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: And add some printf at voice.c when run bb, i used one c118, I can see that the voice data from L2/L3 to L1, and got some data from L1(the first char is 0xd) at l1ctr.c l1ctr_traffic_ind. All seem ok, but the called phone can not hear any data that LCR send, and the LCR also can not get any useful data. Especially I still can hear voice form C118 speaker that the called phone send, and the called phone can hear that the voice data the C118 michone send. But I already changed the audio mode in gsm48_rr.c at gsm48_rr_init. please give me some advice. best regards shrek From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: 570.html=0AI read : "Calypso BTS uses tx_mask and rx_mask to define which s= lots to TX or RX"=0A=0AThen, when looking at the case for 3 phones and tryi= ng to modify tx_mask and rx_mask=0Afor TS 2 could it be=A0 something like t= his?=0A=0Aas -> l1[2].tx_mask=3D0x03 /* TS 2 */=0Aas -> l1[2].rx_mask=3D0x0= 3 /* TS 2 */=0Aas -> l1[1].tx_mask=3D0x02 /* TS 1 */=0Aas -> l1[1].rx_mask= =3D0x02 /* TS 1 */=0Aas -> l1[0].tx_mask=3D0xdf /* TS 5,6,7,0 */=0Aas -> l1= [0].rx_mask=3D0x01 /* TS 0 */=0A=0A=0A/regards=0Aerich =A0 =0A=0A=0A=0ADen = Mandag, 7. juli 2014 23.12 skrev Rusty Dekema :=0A =0A= =0A=0AOn Mon, Jul 7, 2014 at 3:55 PM, trixbox.t wrote= :=0A=0Ahow to add third_phone for TS 2???=0A>=0A=0AOne would have to add at= least the code that accepts the -3, -4, etc option on the command line and= set up the transceiver data structures as appropriate. It is possible that= more work beyond this is needed; I haven't looked at it closely yet.=0A=0A= =0ACheers,=0ARusty D --1353131092-917766482-1404934660=:47158 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
From h= ttp://lists.osmocom.org/pipermail/osmocom-commitlog/2013-February/003570.ht= ml
I read : "Calypso BTS uses tx_mask and rx_mask = to define which slots to TX or RX"

Then, when looking at the case for 3 phones and trying to modify= tx_mask and rx_mask
for TS 2 could it be  so= mething like this?

as -&= gt; l1[2].tx_mask=3D0x03 /* TS 2 */
as -> l1[2]= .rx_mask=3D0x03 /* TS 2 */
as -> l1[1].tx_mask= =3D0x02 /* TS 1 */
as -> l1[1].rx_mask=3D0x02 /= * TS 1 */
as -> l1[0].tx_mask=3D0xdf /* TS 5,6,= 7,0 */
as -> l1[0].rx_mask=3D0x01 /* TS 0 */

/regards
erich  


Den Man= dag, 7. juli 2014 23.12 skrev Rusty Dekema <rdekema at gmail.com>:


On Mon, Jul 7, 2014 at 3:55 PM, = trixbox.t <trixbox.t at yandex.ru= > wrote:
=0A=0Ahow to add third_phone for TS 2???

One would have to add= at least the code that accepts the -3, -4, etc option on the command line = and set up the transceiver data structures as appropriate. It is possible t= hat more work beyond this is needed; I haven't looked at it closely yet.=0A
Cheers,
Rusty D


--1353131092-917766482-1404934660=:47158-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: lot of advanced linux users. You can get help from them as well if you still face issues as they can see your computer screen. Regards, RM From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: lot of advanced linux users. You can get help from them as well if you
still face issues as they can see your computer screen.

Regards,
RM

--047d7b5da6c7ede59304ff644e64-- From bogus@does.not.exist.com Sun Jan 9 15:52:14 2022 From: bogus@does.not.exist.com () Date: Sun, 09 Jan 2022 15:52:14 -0000 Subject: No subject Message-ID: Thanks and Regards, RM On Sat, May 10, 2014 at 4:13 PM, Labs wrote: > Hello, > > In this case it can be some hardware issue with your phone. > If your phone was pre 4.24 software version and it was upgraded it is > possible to have a corrupted EEPROM and you need to use some software tools > to repair it. > > If that is not the case you can try to identify what hardware component is > broken by manually pickup a 900 or 1800 operator and check it if it works. > If one is working and one not this means your duplexer has issues and needs > to be replaced. Other components that might have issues are the PA and > COBBA ICs. Considering that a 3310 you can get for free now it's not worth > it to repair it. > > Regards, > R. > > > On 05/10/2014 05:21 PM, R M wrote: > >> Hi, >> >> The phone is not locked to any network. Its an unlocked phone. I have >> confirmed that. >> >> Thanks and Regards, >> RM >> >> >> On Sat, May 10, 2014 at 7:25 AM, Labs > > wrote: >> >> >> >> On 05/10/2014 12:51 PM, R M wrote: >> >> Hi, >> >> I have recently purchased a SIM card. When I use the SIM in >> Nokia 3310, >> and try to manually select a particular cell, it says no access. >> SIM >> belongs to the same network. >> >> >> Looks like your 3310 has a network lock. Are you sure that your >> phone is unlocked? You can test it with 2 different SIM cards for >> real networks and confirm that it is OK. DCT3 phones can be easily >> unlocked via IMEI. >> >> Regards, >> R. >> >> >> --089e0158c1089091e804f922f13b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for your assistance.

So far from my analysis, this is what I have got:

After the BTS sends Location Update Acc= ept message to the MS, =C2=A0the MS responds with a MM status message sayin= g=C2=A0
"Invalid Mandatory Information".

<= /div>
In a working case, the MS should respond with a TMSI Reallo= cation Complete message which is not happening.

From here, I don't know how to proceed further.
<= div style>
Thanks and Regards,
RM
=


On Sat,= May 10, 2014 at 4:13 PM, Labs <rp.labs at gmx.ch> wrote:
Hello,

In this case it can be some hardware issue with your phone.
If your phone was pre 4.24 software version and it was upgraded it is possi= ble to have a corrupted EEPROM and you need to use some software tools to r= epair it.

If that is not the case you can try to identify what hardware component is = broken by manually pickup a 900 or 1800 operator and check it if it works. = If one is working and one not this means your duplexer has issues and needs= to be replaced. Other components that might have issues are the PA and COB= BA ICs. Considering that a 3310 you can get for free now it's not worth= it to repair it.

Regards,
R.


On 05/10/2014 05:21 PM, R M wrote:
Hi,

The phone is not locked to any network. Its an unlocked phone. I have
confirmed that.

Thanks and Regards,
RM


On Sat, May 10, 2014 at 7:25 AM, Labs <rp.labs at gmx.ch
<mailto:rp.labs at gmx.= ch>> wrote:



=C2=A0 =C2=A0 On 05/10/2014 12:51 PM, R M wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have recently purchased a SIM card. When I us= e the SIM in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nokia 3310,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and try to manually select a particular cell, i= t says no access. SIM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 belongs to the same network.


=C2=A0 =C2=A0 Looks like your 3310 has a network lock. Are you sure that yo= ur
=C2=A0 =C2=A0 phone is unlocked? You can test it with 2 different SIM cards= for
=C2=A0 =C2=A0 real networks and confirm that it is OK. DCT3 phones can be e= asily
=C2=A0 =C2=A0 unlocked via IMEI.

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 R.



--089e0158c1089091e804f922f13b--