Good day OSMOCOM
I see that you have done some tests on the DWM-222 modem/Qualcomm chipset. Do you know if this modem is detected by the Windows11 native cellular connection manager?
D-Link DWM-222 stick - Qualcomm Linux Modems by Quectel & Co - Open Source Mobile Communications
|
|
| |
D-Link DWM-222 stick - Qualcomm Linux Modems by Quectel & Co - Open Sour...
Redmine
|
|
|
Regards,Anish
Hi folks,
I have purchased a DLink DWM-222 with the intention of exploring the
Linux OS running inside it, and if possible, compiling some additional
USB gadgets to use with it.
FWIW, the USB ID's are 2001:ac01 before modeswitch, and 2001:7e3d
after switching.
It creates ttyUSB[0-4] when switched, and the VID:PID added to the
option driver.
I was wondering if there had been any further developments in the
exploration of the A1 hardware or firmware, in terms of gaining a
shell on the device at all without soldering?
Some initial probing has shown some 1.8v signals on some of the test
points, so I will check those with a scope while booting to see if I
can identify some waveforms, hopefully indicating a UART. I do have a
FTDI UART with a voltage reference, so I am fairly confident that I
can access those signals without damaging the device once identified.
Unfortunately, the updated hardware has complete shields over the
interesting bits, so I cannot identify chips, etc. I have also not
been able to find firmware for the A2, the only firmware I could find
was at ftp://ftp.d-link.co.za/DWM/dwm222/Firmware/, marked as A1. I'll
check to see if they are compatible. And of course, will be copying
the driver software from the embedded CDROM.
Regards,
Rogan
Hi friends...
Sorry to disturb you...
I have a Qualcomm Quectel EC25 modem which I can send AT-Commands to this
module with reciving the response. I store this modem diag bytes using a
python opensource app (qcsuper <https://github.com/P1sec/QCSuper>) with a
little code manipulation. Here is a sample diag bytes:
21 00 00 0A 08 01 01 00 00 50 1C 00 04 00 03 03 FF FF 00 FF 11 90 02 00 00
10 00 00 00 EF 1F AA 4C 0B 1E 03 00 00 11 90 02 00 00 00 00 08 01 02 63 ...
02 00 B2 00 4F 00 C0 *7E* 01 00 D2 00 FD 00 C0 8E 00 00 C5 00 C5 01 C0 7E
01 00 BA 00 ... 00 00 00 00 14 *7E* 01 00 50 81 01 00 40 7D 01 00 2C ... 8D
00 00 48 8C 00 00 *7E* 00 00 00 7D 00 00 00 78 00 00
QCSuper can also run Wireshark automatically to dissect RRC Signaling
messages.
I had an experience with Qualcomm Snapdragon mobile phone and after
receiving the bytes I could dissect them using a specific structure. Some
of the patterns of this structures were indicated in a python-c++
opensource app (mobile-insight
<https://github.com/mobile-insight/mobileinsight-core>) e.g. the frames in
the diag bytes starts with *98 00* and timestamp and frame type with a
specific size follow it. Also *7E* is indicated the end of the frame.
Now, I want to know is there a similar structure in this modem diag outputs
to allow for dissecting? Can you offer me a suitable document or app like
mobile-insight?
I saw a project in Osmocom as osmo-qcdiag.
<https://github.com/osmocom/libosmocore> Can I use that to get this
structure?
I hope you help me...
Thank you very much
--
*When there is much light, The shadow is deep...*
Hello,
I am working on a EC25-1 which has problem with the USB communication
with a dwc2 usb host controller [1].
To find the problem my next step was to connect to the EC25 debug UART
on pin 11/12.
But the system needs a root password!
The one you have on your wiki does not work anymore [2].
I think I have the same version "msm LNX.LE.5.0.1-57031-9x40
mdm9607-perf /dev/ttyHSL0"
Do you have another password for this interface or where did you get
this information from?
Thanks for help
Flo
[1] https://www.spinics.net/lists/linux-usb/msg176613.html
[2]
https://osmocom.org/projects/quectel-modems/wiki/EC25_Linux#root-password
Hi All,
i found the problem to start the qmi dial up, can someone help me out.
sudo qmi-network /dev/cdc-wdm0 start
Loading profile at /etc/qmi-network.conf...
APN: isp.docomoiot.net
APN user: unset
APN password: unset
qmi-proxy: yes
Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-format
--device-open-proxy'...
[07 Feb 2019, 09:52:49] -Warning ** [/dev/cdc-wdm0] requested auto mode but
no MBIM QMUX support available
Device link layer protocol retrieved: raw-ip
Getting expected data format with 'qmicli -d /dev/cdc-wdm0
--get-expected-data-format'...
[07 Feb 2019, 09:52:49] -Warning ** [/dev/cdc-wdm0] requested auto mode but
no MBIM QMUX support available
Expected link layer protocol retrieved: 802-3
Updating kernel link layer protocol with 'qmicli -d /dev/cdc-wdm0
--set-expected-data-format=raw-ip'...
[07 Feb 2019, 09:52:49] -Warning ** [/dev/cdc-wdm0] requested auto mode but
no MBIM QMUX support available
error: cannot set expected data format: Expected data format not updated
properly to 'raw-ip': got '802-3' instead
Error updating kernel link layer protocol
Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network=apn='
isp.docomoiot.net' --client-no-release-cid --device-open-proxy'...
[07 Feb 2019, 09:52:49] -Warning ** [/dev/cdc-wdm0] requested auto mode but
no MBIM QMUX support available
error: couldn't start network: QMI protocol error (26): 'NoEffect'
Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 20)
error: network start failed, no packet data handle
[07 Feb 2019, 09:52:49] -Warning ** [/dev/cdc-wdm0] requested auto mode but
no MBIM QMUX support available
Clearing state at /tmp/qmi-network-state-cdc-wdm0...
Thanks
Mashur Khadmi
Hi all,
I've been looking into Qualcomm based devices mainly for collecting radio traces using Holger's diag-parser tool. I'd like to add the information I was able to collect to the Wiki pages (one new device, and some info on the Sierra EM7455 found in Thinkpads mainly).
I've already registered an account in redmine, I'd like to know what's the next step to get to contributing.
Thank you!
Regards,
Domi
Hi list,
While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add
NAS/EPS as a new payload type for gsmtap.h.
Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and
RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS
security had been activated only encrypted NAS messages are available at RRC
layer. This is reflected into the baseband diagnostics of various makers:
Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and
plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this
issue. I can submit a patch if this looks positive.
Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN
is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making
14-bits available for raw value. This causes some problem in LTE:
1) EARFCNs for uplink are starting from 18000, which is larger than 2^14
2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies)
3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network
Also in UMTS, there are overlapping UARFCNs between bands, which necessitates
a separate field for band indicator. Changes regarding these will break the
GSMTAP header structure, therefore I want to discuss about how these could be
addressed.
Best Regards,
Shinjo
--
Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272
To whoever updates the osmocom wiki:
This page: http://osmocom.org/projects/quectel-modems/wiki/Qualcomm_OE_MSM
seems to complain about "forward-slashes in the CFLAGS ?!?"
code:
export EXTRA_CFLAGS="${CFLAGS/Os/O2}"
This syntax is a bash shell substitution construct that replaces "Os" with "O2" in CFLAGS, result in EXTRA_CFLAGS. Probably to adapt to a flavor of gcc.
Maybe that busybox was not compiled with the bash compatibility option?
Regards,
Jean-Pierre
Hello,
Some of you might like to know about a project I released:
https://github.com/scintill/qmiserial2qmuxd
It's a small Linux/Android program to allow projects such as libqmi to
work with qmuxd. It emulates the serial cdc-wdm interface and passes QMI
messages back and forth between qmuxd and a client. There's a README on
Github with more information.
It hasn't been tested very thoroughly yet (I've done several QMI
requests on my Samsung GS4 Mini phone), so I'd welcome your feedback,
contributions, and questions.
For me it's a stepping stone in creating a free Android RIL (early-stage
code at
https://github.com/scintill/android_frameworks_opt_telephony_ril_ofono
), but hopefully some others can get good use out of it too!
Cheers,
Joey
Hi,
I've recently picked up a Quectel EC20 after hearing about the
AT+QLINUXCMD command. While looking around, I somehow managed to get my
device stuck in QDL mode where I have only one ttyUSB available and
lsusb shows the device in QDL Mode.
I have the flashing utility but I don't have an image at hand. Could
anyone send it to me or let me know where I can get it? While searching
I saw ftp://ftp2.quectel.com but that has the kernel source rather than
what I'm looking for,
Thanks.
Hi,
just FYI, I've been told recently, that SIMCom also uses MDM9225 in their
SIM72xx (miniPCIe) and MDM9215 in SIM7100x (SMT format) products.
So I've updated wiki with some basic details at
http://osmocom.org/projects/quectel-modems/wiki/SIMCom
-- ynezz
Hi all,
the ME906v is a Linux-running Qualcomm based modem, which has been first
published about at DEFCON 23
(https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFC…)
It is EOL by now (Huawei probably wants to use HiSilicon these days
rather than Qualcomm) but can be found rather inexpensively from
refurbished suppliers like http://www.minipc.de/de/catalog/il/978
Unfortunately it's M.2 / NGFF and not mPCIe, so it cannot be used in
most embedded devices (PC-Engines, Soekris, ...) or the Osmocom
mPCIE-breakout board.
I have just added some information to our wiki at
https://osmocom.org/projects/quectel-modems/wiki/Huawei_ME906v and
https://osmocom.org/projects/quectel-modems/wiki/Huawei_ME906v_adb
Summary:
* they don't really use the Linux for anything. Not even
QCMAP_ConenctionManager running
* not many HUAWEI modifications recognizable on the Linux side
* no fancy FOTA updates or AT+QLINUXCMD equivalents
* DIAG is present by default
* ADB can be enabled, but requires serial console soldering at least
once :/
Would be nice to find a way to enable adb without having to solder.
I'm still working with Huawei to release the related complete and
corresponding source code under the GPL.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi.
Would be nice to add osmo-qcdiag to the list of projects checked by
https://scan.coverity.com/projects/osmocom?tab=overview
Maybe to https://gerrit.osmocom.org/ too to facilitate contributions via
the same process used by other Osmocom projects.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi Petr,
On Mon, Jan 09, 2017 at 08:57:51PM +0100, Petr Štetiar wrote:
> according to a lot of sources one would think, that EC20 is based around the
> Qualcomm MDM9615, but the picture of naked EC20[1] clearly shows, that there
> is Qualcomm MDM9215 chip soldered on the board. Which source is true? :-) Or
> it's just a wrong text on that BGA?
I think it is simply the fact that (at least) for the Linux on the Cortex-A5 it
doesn't make any difference whether it's running on a 9615 or a 9215.
The difference is presumably primarily in the cellular radio interface
and possibly DSP capacity? From the few publicly available information
the 9615 adds Ev-DO (3GPP2) capability, while the 9215 is GSM/UMTS/LTE
(3GPP) only?
btw: I just created a new mailing list for any future public discussion
on the Qualcomm Linux based cellular modems, see
qc-linux-modems(a)lists.osmocom.org and/or
https://lists.osmocom.org/mailman/listinfo/qc-linux-modems
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)