Comment by ~fuzzy7k on ~anteater/mms-stack-bugs
Modifying that scipt is unnecessary as there is another script,
set-mms-details, that can set the MMSC.
Comment by ~fuzzy7k on ~anteater/mms-stack-bugs
From what I just witnessed, both ofono & mmsd do the right thing here. I haven't dug too deep on this, but it appeared that ofono held the messages until mmsd retrieved them, and mmsd queued the notifications until it was able to fetch the messages. Maybe this could be implemented with the GetMessages method of mmsd? SMS would need the same attention if all of this checks out.
integration added by ~fuzzy7k on ~anteater/mms-stack-bugs
Ticket created by ~fuzzy7k on ~anteater/mms-stack-bugs
I was getting this error after mmsd decoded the initial WAP notification. This was on Ting, a T-mobile MVNO, which does not appear in my mobile-broadband-provider-info database. The problem was that I did not have a MMSC defined. I believe ofono should get this information from the provider database. The following is a workaround using a modified ofono test script.
Append the following to test/create-mms-context:
if len(sys.argv) > 4: context.SetProperty("MessageCenter", sys.argv[4]) print("Setting MMSC to %s" % (sys.argv[4]))Then, run the script
$ test/create-mms-context wholesale "" "" http://wholesale.mmsmvno.com/mms/wapenc Created new context /quectelqmi_0/context2 Setting APN to wholesale Setting username to Setting password to Setting MMSC to http://wholesale.mmsmvno.com/mms/wapenc
mmsd added by ~fuzzy7k on ~anteater/mms-stack-bugs
Comment by ~fuzzy7k on ~anteater/mms-stack-bugs
So, I modified the code in the same manner as it was modified for a not active bearer: src/service.c: 2507:
if (1) {mmsd[1678]: src/service.c:mms_service_push_notify() about to store_meta_open 2 mmsd[1678]: src/service.c:mms_service_push_notify() did store_meta_open 2 mmsd[1678]: src/service.c:mms_service_push_notify() did create_request mmsd[1678]: src/service.c:activate_bearer() service 0x558776bdd0 setup 0 active 0 mmsd[1678]: src/service.c:activate_bearer() service 0x558776bdd0 waiting for 20 seconds mmsd[1678]: plugins/ofono.c:bearer_handler() path /quectelqmi_0 active 1 context_active 1 mmsd[1678]: plugins/ofono.c:bearer_handler() active and context_active, bearer_notify mmsd[1678]: src/service.c:mms_service_bearer_notify() service=0x558776bdd0 active=1 iface=(null) proxy=(null) mmsd[1678]: src/service.c:mms_service_bearer_notify() ignoring inactive mmsd[1678]: src/service.c:mms_service_bearer_notify() interface wwan0 proxy (null) mmsd[1678]: src/service.c:process_request_queue() service 0x558776bdd0Now, the process moves along. I'm still not getting the message in vgmms, but the problem here is that the interface never gets populated.
Comment by ~fuzzy7k on ~anteater/mms-stack-bugs
Try using anteater's git repo for ofono & mmsd. I was getting that error on the t-mobile network until doing so. Might I also suggest changing the title of this bug to
mmsd[]: Failed to handle incoming notification.
Ticket created by ~fuzzy7k on ~anteater/mms-stack-bugs
I am getting and decoding the push notification, but the MMS never downloads....
mmsd[1450]: src/service.c:mms_service_push_notify() about to store_meta_open 2 mmsd[1450]: src/service.c:mms_service_push_notify() did store_meta_open 2 mmsd[1450]: src/service.c:mms_service_push_notify() did create_request mmsd[1450]: src/service.c:activate_bearer() service 0x556ef74dd0 setup 0 active 0 mmsd[1450]: src/service.c:activate_bearer() service 0x556ef74dd0 waiting for 20 seconds mmsd[1450]: plugins/ofono.c:bearer_handler() path /quectelqmi_0 active 1 context_active 1 mmsd[1450]: plugins/ofono.c:bearer_handler() active and context_active, bearer_notify mmsd[1450]: src/service.c:mms_service_bearer_notify() service=0x556ef74dd0 active=1 iface=(null) proxy=(null) mmsd[1450]: src/service.c:mms_service_bearer_notify() interface (null) proxy (null)
Comment by ~fuzzy7k on ~anteater/mms-stack-bugs
Hmm, In ModemManager, messages are not deleted until it is requested, and purple-mm-sms has an option to enable or disable their deletion. It looks like message deletion is specific to the qmimodem driver because of this turd. If ofono does not do something responsible with the message, I would consider that an ofono bug.
Messages should not be deleted until they are 'received'. Actually receiving the message is out of ofono's scope. That's like the mail man shredding your letter because you didn't answer the door.
Comment by ~fuzzy7k on ~anteater/mms-stack-bugs
I was able to move this further along. The "GSM profile" is simply the .nmconnection and the device-id is I believe some type of hash that NM creates. Now that I think about it, I'm not sure why I was getting that error after deleting the device-id property. I may have forgotten some detail.
However, after resolving that I was getting
Error: Connection activation failed: Connection 'ofono' is not available on device quectelqmi_0 because profile is not compatible with device (modem is incompatible with connection: the connection ID has no context)which comes from src/devices/wwan/nm-modem-ofono.c
It turns out that the ofono plugin is very specific about the connection id. I am guessing this is by ofono design because connman uses a similar syntax for managing ofono connections and looking at the connman connection was key to setting a connection id that NM will accept.
$ enable-modem $ online-modem $ connmanctl connmanctl> servicesWhich spits out a carrier ID and something that looks like
cellular_#imsi#_context1Using that,
$ nmcli c connection-id edit nmcli>set connection.id cellular/#imsi#/context1/'s are important
Now, it tries to connect, but stalls out on:
NetworkManager[260]: <info> [1601915316.9656] device (quectelqmi_0): Activation: starting connection 'cellular/310260098374532/context1' (144b21c9-17f2-3776-9b2d-a463cdab88db) NetworkManager[260]: <info> [1601915316.9662] audit: op="connection-activate" uuid="144b21c9-17f2-3776-9b2d-a463cdab88db" name="cellular/310260098374532/context1" pid=745 uid=1000 result="success" NetworkManager[260]: <info> [1601915316.9671] device (quectelqmi_0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') NetworkManager[260]: <info> [1601915316.9708] manager: NetworkManager state is now CONNECTING NetworkManager[260]: <info> [1601915316.9724] modem-ofono[quectelqmi_0]: activating context /quectelqmi_0/context1