I have AT&T, and I am using the Mobian OS on the PinePhone. I was able to build ofono, mmsd, and vgmms successfully with the following commands:
#dependencies
sudo apt install make gcc automake libtool-bin autotools-dev libudev-dev libdbus-1-dev libglib2.0-dev libcairo2-dev libjpeg-dev libgif-dev libpango1.0-dev libgdk-pixbuf2.0-dev librust-atk-dev librust-gdk-dev libsqlite3-dev
#install rust
curl https://sh.rustup.rs -sSf | sh
#clone the repos
cd ~
mkdir mms
cd mms
git clone https://git.sr.ht/~anteater/vgmms
git clone https://git.sr.ht/~anteater/mmsd
git clone https://git.sr.ht/~anteater/ofono
git clone https://github.com/bryanperris/ell.git
#build ofono (requires the ell repo to be in the parent dir)
cd ofono
./bootstrap-configure && make && sudo make install
#build mmsd (most recent commit might not work)
cd mmsd
git checkout f4b8b32477a411180be1823fdc460b4f7e1e3c9c
./bootstrap-configure && make && sudo make install
#build vgmms (only use 1 CPU core to avoid locking up)
cd ..
cd vgmms
cargo build -j 1 --release
#to run vgmms, start the daemons, then run the executable
sudo service ofono start
/usr/libexec/mmsd
~/mms/vgmms/target/release/vgmms
However, when I ran vgmms I got the following error:
mobian@mobian:~$ RUST_BACKTRACE=1 ~/mms/vgmms/target/release/vgmms
thread 'main' panicked at 'expected 1 modem, got 2', src/state.rs:195:19
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1069
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1504
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:511
11: rust_begin_unwind
at src/libstd/panicking.rs:419
12: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:373
13: vgmms::state::<impl core::default::Default for vgmms::types::VgmmsState>::default
14: <std::sync::rwlock::RwLock<T> as core::default::Default>::default
15: vgtk::component::PartialComponentTask<C,P>::new
16: vgtk::start
17: vgmms::main
18: std::rt::lang_start::{{closure}}
19: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:52
20: std::panicking::try::do_call
at src/libstd/panicking.rs:331
21: std::panicking::try
at src/libstd/panicking.rs:274
22: std::panic::catch_unwind
at src/libstd/panic.rs:394
23: std::rt::lang_start_internal
at src/libstd/rt.rs:51
24: main
25: __libc_start_main
26: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
After adding this hack
[m] => m.to_owned(), [m1,m2] => m1.to_owned(), //added this line ms => panic!("expected 1 modem, got {}", ms.len()),
I am getting a new error:
mobian@mobian:~/mms/vgmms$ RUST_BACKTRACE=1 ~/mms/vgmms/target/release/vgmms thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: D-Bus error: Method "GetProperties" with signature "" on interface "org.ofono.SimManager" doesn't exist (org.freedesktop.DBus.Error.UnknownMethod)', src/state.rs:198:25 stack backtrace: 0: backtrace::backtrace::libunwind::trace at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86 1: backtrace::backtrace::trace_unsynchronized at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66 2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:78 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59 4: core::fmt::write at src/libcore/fmt/mod.rs:1069 5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1504 6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62 7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49 8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:198 9: std::panicking::default_hook at src/libstd/panicking.rs:218 10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:511 11: rust_begin_unwind at src/libstd/panicking.rs:419 12: core::panicking::panic_fmt at src/libcore/panicking.rs:111 13: core::option::expect_none_failed at src/libcore/option.rs:1268 14: vgmms::state::<impl core::default::Default for vgmms::types::VgmmsState>::default 15: <std::sync::rwlock::RwLock<T> as core::default::Default>::default 16: vgtk::component::PartialComponentTask<C,P>::new 17: vgtk::start 18: vgmms::main 19: std::rt::lang_start::{{closure}} 20: std::rt::lang_start_internal::{{closure}} at src/libstd/rt.rs:52 21: std::panicking::try::do_call at src/libstd/panicking.rs:331 22: std::panicking::try at src/libstd/panicking.rs:274 23: std::panic::catch_unwind at src/libstd/panic.rs:394 24: std::rt::lang_start_internal at src/libstd/rt.rs:51 25: main 26: __libc_start_main 27: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Hi! Thanks for testing and sorry for the delayed response.
The first error is surprising--the PinePhone should only have one modem as far as I know. Can you try the
list-modems
tool from ofono'stest
directory and post its output?The second error likely indicates you need to poweron and online your modem. This can be done with
ofonoctl poweron && ofonoctl online
or with theenable-modem
andonline-modem
scripts (again, in ofono'stest
directory).I should do some testing from a more blank-slate phone setup and document the testing steps better to correct this missing stair. In addition, vgmms should improve its handling here; bug #14 is related.
Hello,
What may be the issue is that Modemmanager has complete control of the modem. You may need to disable that first.
I'm trying to build it again so I can test this, but I'm having issues. I submitted a new report #19 for those issues.
ofono's list-modems tool gave this output:
[ /quectelqmi_0 ] Online = 0 Powered = 0 Lockdown = 0 Emergency = 0 SystemPath = /sys/devices/platform/soc/1c1b000.usb/usb3/3-1 Interfaces = Features = Type = hardware [ /stktest ] Online = 0 Powered = 0 Lockdown = 0 Emergency = 0 Interfaces = Features = Type = test
After running enable-modem and online-modem, /quectelqmi_0 is populated with a lot more info, and some of it is probably private so I will not post it here. Then I tried the hack I described above:
[m1,m2] => m1.to_owned()
, and I got a new error:expected 1 subscriber number, found 0 thread 'main' panicked at 'could not determine subscriber phone number', src/state.rs:198:25 stack backtrace: 0: 0xaaaabfd40e00 - backtrace::backtrace::libunwind::trace::h0d05004ec20df245 at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86 1: 0xaaaabfd40e00 - backtrace::backtrace::trace_unsynchronized::h740688500eec7531 at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66 2: 0xaaaabfd40e00 - std::sys_common::backtrace::_print_fmt::h0a24304707227b33 at src/libstd/sys_common/backtrace.rs:78 3: 0xaaaabfd40e00 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hfcfb6df60d9c8b73 at src/libstd/sys_common/backtrace.rs:59 4: 0xaaaabfd5df6c - core::fmt::write::h9fde878a1f9dff47 at src/libcore/fmt/mod.rs:1076 5: 0xaaaabfd3e450 - std::io::Write::write_fmt::h6d4f85a2ba0f2d5f at src/libstd/io/mod.rs:1537 6: 0xaaaabfd432a0 - std::sys_common::backtrace::_print::hec62e4e9271d9223 at src/libstd/sys_common/backtrace.rs:62 7: 0xaaaabfd432a0 - std::sys_common::backtrace::print::h84a52accb21a613a at src/libstd/sys_common/backtrace.rs:49 8: 0xaaaabfd432a0 - std::panicking::default_hook::{{closure}}::h44fa84a1f3c85cf5 at src/libstd/panicking.rs:198 9: 0xaaaabfd42fe0 - std::panicking::default_hook::hf53a525a8c837f1f at src/libstd/panicking.rs:218 10: 0xaaaabfd43910 - std::panicking::rust_panic_with_hook::h31170e69b0c9835c at src/libstd/panicking.rs:486 11: 0xaaaabfd4353c - rust_begin_unwind at src/libstd/panicking.rs:388 12: 0xaaaabfd5c9f0 - core::panicking::panic_fmt::hc4c8ea1a99c4f131 at src/libcore/panicking.rs:101 13: 0xaaaabfd5c864 - core::option::expect_failed::h54f8b971aaeb4348 at src/libcore/option.rs:1264 14: 0xaaaabfb911e8 - vgmms::state::<impl core::default::Default for vgmms::types::VgmmsState>::default::hf9374a3019a11ffa 15: 0xaaaabfbdacf8 - <std::sync::rwlock::RwLock<T> as core::default::Default>::default::h4154681b088512a5 16: 0xaaaabfbc8ba4 - vgtk::component::PartialComponentTask<C,P>::new::h8c8a99f2959d7489 17: 0xaaaabfc0d1c8 - vgtk::start::had3226e83d2b5b6b 18: 0xaaaabfbb3fb8 - vgmms::main::h26c82e214666ee70 19: 0xaaaabfbf8c4c - std::rt::lang_start::{{closure}}::h9b4495c7249d3c69 20: 0xaaaabfd43c80 - std::rt::lang_start_internal::{{closure}}::h0eb9753eeb12f78a at src/libstd/rt.rs:52 21: 0xaaaabfd43c80 - std::panicking::try::do_call::h821f30619b2948f1 at src/libstd/panicking.rs:297 22: 0xaaaabfd43c80 - std::panicking::try::hac74bff921d0f66c at src/libstd/panicking.rs:274 23: 0xaaaabfd43c80 - std::panic::catch_unwind::h0ea93cfaed3ccfc8 at src/libstd/panic.rs:394 24: 0xaaaabfd43c80 - std::rt::lang_start_internal::heaa2e839c79dc49f at src/libstd/rt.rs:51 25: 0xaaaabfbb40d8 - main 26: 0xffff8925c158 - __libc_start_main 27: 0xaaaabfb762a8 - <unknown>
I switched the hack to use the 2nd modem instead of the first:
[m1,m2] => m2.to_owned()
and got the same error as my post earlier, with an identical backtrace:thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: D-Bus error: Method "GetProperties" with signature "" on interface "org.ofono.SimManager" doesn't exist (org.freedesktop.DBus.Error.UnknownMethod)', src/state.rs:198:25
All of this makes me think that the first one is what I want, but there is some step I'm missing to give it the phone number.
The first modem is what you want; the second is ofono's "test" dummy modem. I'm surprised it's present, but you may have enabled it when debugging other functionality or it may be set up by your distro. Either way, your hack to choose
m1
should work.The output of
list-modems
after poweron/online on the modem is the data vgmms is looking at. The important section is theorg.ofono.SimManager
section. For me, it looks (anonymized) like this:[ org.ofono.SimManager ] Present = 1 CardIdentifier = <private> SubscriberIdentity = <private, starts with the below 3 digit quantities concatenated> FixedDialing = 0 BarredDialing = 0 MobileCountryCode = <private, 3 digits> MobileNetworkCode = <private, 3 digits> SubscriberNumbers = <private, 10 digits, my phone number> LockedPins = PreferredLanguages = en PinRequired = none Retries = [pin = 3] [pin2 = 10] [puk = 10] [puk2 = 10] CardSlotCount = 1 ActiveCardSlot = 1
vgmms looks at the
SubscriberNumbers
array, expecting 1 number. If yourlist-modems
output has your phone number (or some phone number) listed inSubscriberNumbers
, this is a bug in vgmms. If not, something is wrong elsewhere in the stack (either ofono, your SIM, or your telco account).
Here is my SimManager section. The SubscriberNumbers section is completely blank! I am able to make phone calls and texts however, so can I rule out a faulty SIM card? How would I go about debugging ofono?
[ org.ofono.SimManager ] Present = 1 CardIdentifier = <private> SubscriberIdentity = <private> FixedDialing = 0 BarredDialing = 0 MobileCountryCode = <private> MobileNetworkCode = <private> SubscriberNumbers = LockedPins = PreferredLanguages = en PinRequired = none Retries = [pin = 2] [pin2 = 2] [puk = 10] [puk2 = 10] CardSlotCount = 1 ActiveCardSlot = 1
As far as I'm aware the SubscriberNumbers field is the only way ofono communicates this information, so this seems like either an ofono bug or a SIM issue. vgmms is behaving as expected.
Strictly speaking, it might not be necessary to know the user's own number to send/receive SMS, but for MMS it is necessary to know the user's number to avoid showing them as another recipient on received group messages. And ofono should really be providing this information.
Do the ofono tools (e.g.
test/send-sms
) work to send SMS messages? And does the ModemManager stack manage to determine the phone number? (ModemManager stores this info in its OwnNumbers property.)There are a few ways to determine the phone number from a SIM card. I think ofono primarily tries to do it by reading the
EFmsisdn
file on the SIM card, but an AT command can also be used. I wonder if your SIM has a malformed or unusualEFmsisdn
file. I think ModemManager has better logging around reading this file, so it might be informative to try that stack and see what shows up in logs and whether it's able to determine the phone number.
Apologies if this is a bit off-topic, but can you link to an explanation of these lines?:
#build mmsd (most recent commit might not work) cd mmsd git checkout f4b8b32477a411180be1823fdc460b4f7e1e3c9c
When I did that, I didn't know how to fix the build error so I just went back until I found a commit that would build. Just now I rebuilt mmsd using the latest commit by disabling -Werror in the makefile and it worked.
After rebooting, and executing the following commands:
~/mms/ofono/test/enable-modem ~/mms/ofono/test/online-modem sudo service ofono start sudo /usr/libexec/mmsd ~/mms/vgmms/target/release/vgmms
It worked - I was able to run vgmms! However, I am having issues with sending a message which I have submitted as #23
I think your issue is running
/usr/libexec/mmsd
as root. I'll clarify in the README that ofono must run as root (because it controls the modem device) and MMSd as your user (because it only listens to ofono, makes network requests, and saves MMS data in your home directory).Another thing to note is that you should start ofono before running enable-modem and online-modem, as these communicate with the running
ofonod
instance.Edit: Clarified in 55ccafa9.
I also encountered this error, and seemed to get around it with the hack:
[m] => m.to_owned(), [m1,m2] => m1.to_owned(), //added this line ms => panic!("expected 1 modem, got {}", ms.len()),
It looks like the
stktest
modem may be present as a result of running./bootstrap-configure
, which enables maintainer mode and builds and enables thestktest
module. Try building ofono afresh with./configure
arguments along the lines of these:./configure --enable-debug --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var
~johanvandegriff, when you get a chance, try to build ofono with a different configure command (omitting
--enable-maintainer-mode
) and verify whether the right number of modems is present. If you see a single modem, this bug report can be closed.
I rebuilt ofono without the --enable-maintainer-mode switch (which also removed -Werror from the Makefile), and rebuilt vgmms without my hack. This solved the original issue of finding 2 modems as now the output of
ofono/test/list-modems
only has[ /quectelqmi_0 ]
! (Issue #23 still persists withBadSenderOrSentTime
however.) I have documented my complete build steps in this post: https://blog.johanv.xyz/how-to-send-mms-messages-on-the-pinephone-with-vgmms
~johanvandegriff does the fact your blog post says "How to send MMS" but #23 is still a problem imply that MMS (send+receive) works 1:1 (e.g. photo messages) but not with group messages?
~amindfv i hadnt tried sending a photo, but now when i tried to the app crashed so i submitted a new bug report #39. my intention with the blog post was that i would keep track of what i did so that eventually once it works it is reproducable. i added a note to the blog post that it doesnt work right now