I am assuming you installed the debian package. did you install both mmsd and mmsd-dgbsym? if you didn’t install mmsd-dbgsym is likely why you don’t see much.
Else, try stopping the systemd service and just build from the master branch and run it in the foreground
OK, I will work on it tomorrow. If I collect the log, how do I get it to you?
Either DM me here, or find me on matrix (which may be better).
Also, take a look at this:
This may be what you are seeing too. It’s also why I said mmsd needs a front end. While mmsd fully supports MMS, it is a backend app only, and not terribly useful without a front end.
So I installed updates today. It installed new ModemManager and chatty. So now MMS’ s no longer work. If I reinstall the ModemManager I built yesterday, then chatty no longer starts. So there was an API change in the updated ModemManager that chatty depends on in the new chatty. When I reinstall the new ModemManager chatty starts but now any MMS hang up everything again. I don’t know how I can revert to the previous chatty so I can used the ModemManager I had built yesterday.
In fact, probably it installed old ModemManager again. 
This is an annoyance that I noticed also, after we have installed our own carefully patched packages, when installing updates using apt upgrade it will reinstall the old versions again. Apparently apt considers the default versions to be “newer” than the manually installed patched versions, so it wants to reinstall the default versions. Therefore it always says there are “updates available” after installing the patched deb files. There is probably a better way to do things to avoid this problem by having apt leave the manually installed packages alone, but right now I don’t know how.
So far, the only way I know to handle it is that after installing updates I need to reinstall the .deb files for libqmi and modemmanager: go into each of those directories where the deb files are, the deb files that you built yesterday, and run sudo dpkg --install *.deb there to install them again.
Based on what you wrote, it sounds like you reinstalled ModemManager but you did not reinstall the libqmi stuff. I suspect that may be your problem, because the patched ModemManager needs the patched libqmi to work. My theory is that when you installed updates that resulted in both libqmi and ModemManager being reverted to the default versions. Then, to make things work again you need to reinstall the patched versions of both libqmi and ModemManager. Does that help?
You’re right, when I reinstalled the packages built yesterday I missed libqmi. Back to working the same as yesterday now. Thanks very much. I have now put a hold on updating ModemManager for the time being.
Great. Any luck getting debug output from mmsd?
For me it works to first kill it by doing killall mmsd (then you kill the mmsd process that was started automatically by the systemd service), then after that you can run your own mmsd process with debug output enabled like this:
./mmsd/src/mmsd -n -d
or
./mmsd/src/mmsd -n -d > logfile.txtHere is an excerpt from the log. It found type PLMN
msd[1741]: src/mmsutil.c:mms_parse_headers() handler for type 9 was success
mmsd[1741]: src/mmsutil.c:mms_parse_headers() saw header of type 11
mmsd[1741]: src/mmsutil.c:mms_parse_headers() running handler for type 11
mmsd[1741]: src/mmsutil.c:decode_text() claimed len: 37
mmsd[1741]: src/mmsutil.c:decode_text() val: 39eb6af5-ab99-4837-b504-2513992c7316
mmsd[1741]: src/mmsutil.c:mms_parse_headers() handler for type 11 was success
mmsd[1741]: src/mmsutil.c:mms_parse_headers() saw header of type 5
mmsd[1741]: src/mmsutil.c:mms_parse_headers() running handler for type 5
mmsd[1741]: src/mmsutil.c:mms_parse_headers() handler for type 5 was success
mmsd[1741]: src/mmsutil.c:mms_parse_headers() saw header of type 6
mmsd[1741]: src/mmsutil.c:mms_parse_headers() saw header of type 25
mmsd[1741]: src/mmsutil.c:mms_parse_headers() type isn’t a part of the standard? Skipping 26
mmsd[1741]: src/mmsutil.c:extract_content_id() extracted content-id
So it looks like it found the data. Where is it writing this stuff?
Look in:
look in $HOME/.mms/modemmanager/
See if your experience matches: https://source.puri.sm/kop316/mmsd/-/issues/9
Yes, I am getting the same thing. I thought it would be just the image but it does appear to have headers in it as well. I get the same result with AutoProcessSMSWAP=false or true. Maybe that only makes a difference when running mmsd as a daemon. So is there supposed to be something parsing this out? Chatty apparently isn’t. Is purple-mm-sms supposed to be called by something (mmsd) to do it?
Thanks again for all your help.
I get the same result with AutoProcessSMSWAP=false or true
It sounds like you have puruple-mm-sms installed then.
So is there supposed to be something parsing this out?
That would be the job of chatty and/or purple-mm-sms. mmsd is a backend only. You are also free to program your own front end to get it to work. That’s why AutoProcessSMSWAP exists, to give the front end dev freedom to do how they want to.
Is purple-mm-sms supposed to be called by something (mmsd) to do it?
purple-mm-sms is used by chatty to do all of this. I made a reference implimentation for chatty without libpurple too.
@kop316, in fact I would be interested in seeing the exact format of the file. I assume this is a MMS Message Body, of which there can be multiple in an MMS Message. I haven’t found the exact format of this yet. Do you have a pointer to a specification for that? Or sample code or a sample algorithm?
Thanks.
I think this is the specific document: http://openmobilealliance.org/release/MMS/V1_1-20021104-C/OMA-WAP-MMS-ENC-V1_1-20021030-C.pdf
Here you go. mmsd has a “decode-mms” file too.
You can also open up the file in a hex editor.
As I understand it, here is how it should work, and how it works for me (@kop316 please correct me if I’m wrong here):
~/.mms/modemmanager/ directory~/.mms/modemmanager/ and converts it to the final MMS contents which are then stored in the ~/mms/ directory (note the difference between ~/.mms/ and ~/mms/ (without the dot).Maybe in your case, what happens is point 1-3 above but point 4 does not happen. That could indicate that you don’t have the patched purple-mm-sms installed. The crucial thing I think is the file mm-sms.so installed at /usr/lib/purple-2/mm-sms.so – note that it is not enough that such a file exists, it needs to really come from the patched purple-mm-sms build. If you forgot to do “sudo make install” for purple-mm-sms or if the default version was reinstalled later by apt then that could explain it. Anyway, one thing you could try is to do “sudo make install” for purple-mm-sms again, then reboot and try receiving MMS again.
Thanks. I already did open it up in a hex editor but the format is not obvious of course.
Note this all happens over the dbus. No program is looking for file changes.
So you know, mmsd does all the of the hard work for you over the dbus. It will slit out a dbus message giving you all of the headers, a location to the SMIL, and each attachment
So I extracted and rebuilt the kop316 version purple-mm-sms from scratch and then installed it again. I verified there was a new version in /usr/lib/purple-2 of mm-sms.so. I never get anything in ~/mms just in /.mms/modemmanager. So is there a patched version of chatty I need? If not, how do I get log output from mm-sms.so and/or chatty when this step is supposed to be happening? Does chatty have some configuration somewhere to tell it to uses mm-sms.o, does it register to chatty somehow, or does chatty look for it? I see there is ~/.purple/prefs.xml but mm-sms.o is not listed in the plugins section.
Thanks.
Good, but did you reboot after that? If chatty was already running when you installed the new mm-sms.so then maybe it could happen that chatty was still using the old one that had been loaded into memory earlier.
No, this should work with the standard version of chatty.
You can kill the autostarted chatty by doing killall chatty a few times (it is restarted again automatically the first time but if you kill it again it gives up). Then you can start chatty with debug output like this:
chatty --debug
Then you get lots of debug output from chatty, you can check if anything happens when an MMS is received.
I don’t know but at least you can verify that chatty has loaded the shared library file, like this: First find out the current process id (pid) of chatty like this:
pgrep chatty
That gives you a number that is the PID. Then you can use the lsof command to list all open files (including shared libraries that we are interested in now) for that process, and you can see if it shows a path to mm-sms.so – for me it looks like this:
purism@pureos:~$ lsof -p 5155 | grep sms
chatty 5155 purism mem REG 179,2 45496 143787 /usr/lib/purple-2/mm-sms.so
I also have that file and it does not say anything about mm-sms for me either, but chatty still loads mm-sms.so so apparently chatty decides that in some other way, regardless of that xml file.
Anyway, hopefully the debug output from chatty can give some clue to what goes wrong.