Calling (almost) unusable since Byzantium update

5890238590 · December 4, 2021, 6:45pm

I’ve updated to Byzantium today, and it seems that calling is now almost unusable for me. I wanted to post this here not to rant, but to see if others are experiencing similar problems and might have pointers to get this resolved or to existing related tickets I can monitor.

Minor Problems with Amber

With Amber, calling mostly worked fine. I ran into an issue yesterday with Amber where someone tried calling me, but the phone never registered someone calling - I had very good reception at the time. What’s worse, the call was never registered as missed either. I killed and restarted the modem using the hardware kill switch, after which I could properly call and receive calls again - note that the missed call was still never added to the calls overview, so if the person hadn’t told me, I wouldn’t have known at all (unfortunately this also was an important call from work, as I use the Librem professionally).

Major Problems With Byzantium

Because Byzantium was released, I figured it was time to update today since there might be fixes not being backported to Amber. I did so today, immediately started testing basic calling, and it is… abysmal, without exaggerating. It might partially be related to the fact that I live in a place where reception is generally poor, but at certain spots it usually works fine. Even so, I’d expect the GUI and software to be able to deal with that and at least stay in a consistent state. The list below shows my initial experience with Byzantium; I had two bars of reception and 4G continuously and did not move my location:

I started a call from my contacts list by clicking the phone icon. The GUI never switched to the calling screen. I tried tapping it a couple of times, but to no avail. Since I was calling the fixed phone in the home I was in, the phone suddenly started ringing - it was me, calling, but the Librem phone never indicated it started calling. Because of this, there was also no way to stop calling.
I restarted the modem and tried again, this time using the dial page. The Librem phone went to the calling screen, and my fixed phone started ringing. After four seconds, the Librem phone bailed and went back to my calls overview for some reason. The fixed phone was still ringing, mind you, again with no way to cancel the call.
I restarted the modem and tried calling myself from the fixed phone. It immediately went to voice mail. I tried this three times. (This could be due to bad reception, though I had proper reception according to the Librem.)
In one case the call never went through to my fixed phone - it never started ringing -, but I was on the calling screen on the Librem, and pressing the red phone icon to stop the call did nothing… until about a minute later, when it jumped back to the calls overview (there were errors in the logs, see also below).
I tried restarting the phone in the above situations too, to no avail.
After restarting the phone, I tried calling myself again. This time it went through. I managed to do two calls in both directions and it worked fine this time (great!).
I tried doing another call from another location in my home where there was slightly better reception. The call went through, but again the Librem went to the overview by itself after a couple of rings, and the fixed phone kept ringing, again with no way to cancel the call.
I tried that again, again after a restart of the phone, and, after picking up the fixed phone, I could hear the other person speak, but they could not hear me. They were hearing all kinds of tapping noises instead. I think these tapping noises might be noises I was making 10 minutes earlier, to test calls when I was handling both phones myself, but I’m not sure, which could indicate a sound buffer issue.
Even when the call went through, the Librem often did not give a ringing sound.

Maybe I flashed the wrong Byzantium? I have a Librem phone from January 2021, and I just flashed using ./scripts/librem5-flash-image --variant luks --skip-cleanup, so I assume it selected the appropriate model. The flash also succeeded without issues.

(Obviously I don’t have the microphone killed or anything during this test.)

For some of these issues, I captured journal logs, which hopefully can be helpful to someone. I’m very happy a Linux phone exists, know some things are still WIP, but I at least expect (need) calling to be working in a somewhat stable fashion, so I’d be happy to report these to their respective projects if someone wishes me to, or to aid in debugging the issues further.

Logs 1 - Call Not Going Through, Screen Stuck

I stared a call, the Librem phone went to the calling screen:


ec 04 18:42:06 librem ModemManager[717]: <info> [modem2/call0] user request to start call

dec 04 18:42:06 librem ModemManager[717]: <info> [modem2/call0] call state changed: unknown -> dialing (outgoing-started)

dec 04 18:42:07 librem gsd-color[984]: unable to get EDID for xrandr-DSI-1: unable to get EDID for output

dec 04 18:42:18 librem ModemManager[717]: <info> [modem2] 3GPP registration state changed (home -> idle)

dec 04 18:42:18 librem ModemManager[717]: <info> [modem2] 3GPP registration state changed (idle -> registering)

dec 04 18:42:18 librem ModemManager[717]: <info> [modem2] 3GPP registration state changed (registering -> home)

dec 04 18:42:20 librem phosh[1589]: The XKEYBOARD keymap compiler (xkbcomp) reports:

dec 04 18:42:20 librem phosh[1589]: > Warning: Unsupported maximum keycode 569, clipping.

dec 04 18:42:20 librem phosh[1589]: > X11 cannot support keycodes above 255.

dec 04 18:42:20 librem phosh[1589]: Errors from xkbcomp are not fatal to the X server

dec 04 18:42:21 librem pulseaudio[777]: ALSA woke us up to write new data to the device, but there was actually nothing to write.

dec 04 18:42:21 librem pulseaudio[777]: Most likely this is a bug in the ALSA driver 'snd_soc_simple_card'. Please report this issue to the ALSA developers.

dec 04 18:42:21 librem pulseaudio[777]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

dec 04 18:42:31 librem gnome-calls[1144]: Error starting outgoing call ModemManager call to `<NUMBER>': Tijd is verlopen

(Note the ALSA and PulseAudio errors. “Tijd is verlopen” is Dutch for “Expired”.)

The call never goes through at this point, even though the Librem pretends it’s ringing. I press the red phone icon to stop calling. It doesn’t do anything, I see this in the logs every time I press it:


<info> [modem2/call0] user request to hangup call but never happened, screen stuck

After a minute or so, the call finally stops with the following logs:


dec 04 18:43:37 librem ModemManager[717]: <warn> [modem2/call0] couldn't start call: Serial command timed out

dec 04 18:43:37 librem ModemManager[717]: <info> [modem2/call0] call state changed: dialing -> terminated (unknown)

dec 04 18:43:37 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 2 consecutive times

dec 04 18:43:40 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:42 librem ModemManager[717]: <warn> [modem2] couldn't load call list: Serial command timed out

dec 04 18:43:42 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 3 consecutive times

dec 04 18:43:42 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:43 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:43 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:43 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:43 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:44 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 4 consecutive times

dec 04 18:43:44 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:44 librem gnome-calls[1144]: Error hanging up ModemManager call to `<NUMBER>': Tijd is verlopen

dec 04 18:43:46 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 5 consecutive times

dec 04 18:43:48 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 6 consecutive times

dec 04 18:43:50 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 7 consecutive times

dec 04 18:43:52 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 8 consecutive times

dec 04 18:43:54 librem ModemManager[717]: <warn> [modem2] port ttyUSB1 timed out 9 consecutive times

dec 04 18:43:56 librem ModemManager[717]: <error> [modem2] port ttyUSB1 timed out 10 consecutive times, marking modem as invalid

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'wds' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'wds' client with ID '2'

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'wds' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'wds' client with ID '1'

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'voice' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'voice' client with ID '2'

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'pdc' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'pdc' client with ID '1'

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'loc' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'loc' client with ID '1'

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'uim' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'uim' client with ID '1'

dec 04 18:43:56 librem NetworkManager[500]: <info> [1638639836.0716] device (cdc-wdm0): state change: activated -> unmanaged (reason 'removed', sys-iface-state: 'removed')

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'wms' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'wms' client with ID '1'

dec 04 18:43:56 librem systemd-networkd[407]: wwan0: Link DOWN

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'nas' client with flags 'release-cid'...

dec 04 18:43:56 librem systemd-networkd[407]: wwan0: Lost carrier

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'nas' client with ID '1'

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Releasing 'dms' client with flags 'release-cid'...

dec 04 18:43:56 librem ModemManager[717]: [/dev/cdc-wdm0] Unregistered 'dms' client with ID '1'

dec 04 18:43:56 librem dbus-daemon[496]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=500 comm="/usr/sbin/NetworkManager --no-daemon ")

dec 04 18:43:56 librem systemd[1]: Starting Network Manager Script Dispatcher Service...

dec 04 18:43:56 librem NetworkManager[500]: <warn> [1638639836.1511] modem-broadband[cdc-wdm0]: failed to disconnect modem: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.ModemManager1.Modem.Simple” on object at path /org/freedesktop/ModemManager1/Modem/2

dec 04 18:43:56 librem dbus-daemon[496]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

dec 04 18:43:56 librem systemd[1]: Started Network Manager Script Dispatcher Service.

dec 04 18:43:59 librem ModemManager[717]: transaction 0x10 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x11 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x12 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x13 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x14 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x15 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x16 aborted, but message is not abortable

dec 04 18:43:59 librem ModemManager[717]: transaction 0x17 aborted, but message is not abortable

Logs 2 - PulseAudio Errors

During some calls, when I was not talking, a large amount of PulseAudio errors were being spammed:


98]: unable to get EDID for xrandr-DSI-1: unable to get EDID for output

dec 04 18:54:34 librem pulseaudio[772]: ALSA woke us up to write new data to the device, but there was actually nothing to write.

dec 04 18:54:34 librem pulseaudio[772]: Most likely this is a bug in the ALSA driver 'snd_soc_simple_card'. Please report this issue to the ALSA developers.

dec 04 18:54:34 librem pulseaudio[772]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

dec 04 18:54:36 librem ModemManager[593]: <info> [modem0/call0] user request to accept call

dec 04 18:54:36 librem ModemManager[593]: <warn> [modem0] unexpected incoming call to number 'n/a' reported in call list: state active

dec 04 18:54:36 librem ModemManager[593]: <info> [modem0/call0] call is accepted

dec 04 18:54:36 librem ModemManager[593]: <info> [modem0/call0] call state changed: ringing-in -> active (accepted)

dec 04 18:54:36 librem pulseaudio[772]: Configured maximum latency is smaller than latency, using latency instead

dec 04 18:54:36 librem pulseaudio[772]: Cannot set requested sink latency of 50,00 ms, adjusting to 100,00 ms

dec 04 18:54:36 librem pulseaudio[772]: Cannot set requested source latency of 50,00 ms, adjusting to 100,00 ms

dec 04 18:54:36 librem pulseaudio[772]: Configured maximum latency is smaller than latency, using latency instead

dec 04 18:54:36 librem pulseaudio[772]: Cannot set requested sink latency of 50,00 ms, adjusting to 100,00 ms

dec 04 18:54:36 librem pulseaudio[772]: Cannot set requested source latency of 50,00 ms, adjusting to 100,00 ms

dec 04 18:54:36 librem pulseaudio[772]: Doing resync

dec 04 18:54:36 librem pulseaudio[772]: Playback after capture (-72845), drop sink 28048

dec 04 18:54:36 librem pulseaudio[772]: Configured latency of 200,00 ms is smaller than minimum latency, using minimum instead

dec 04 18:54:36 librem pulseaudio[772]: ALSA woke us up to read new data from the device, but there was actually nothing to read.

dec 04 18:54:36 librem pulseaudio[772]: Most likely this is a bug in the ALSA driver 'snd_soc_simple_card'. Please report this issue to the ALSA developers.

dec 04 18:54:36 librem pulseaudio[772]: Cannot set requested source latency of 60,75 ms, adjusting to 100,00 ms

dec 04 18:54:36 librem pulseaudio[772]: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

dec 04 18:54:36 librem pulseaudio[772]: Cannot set requested sink latency of 50,00 ms, adjusting to 100,00 ms

dec 04 18:54:36 librem callaudiod[968]: no available input found!

dec 04 18:54:36 librem callaudiod[968]: no available output found!

dec 04 18:54:36 librem callaudiod[968]: no available input found!

dec 04 18:54:36 librem pulseaudio[772]: Doing resync

dec 04 18:54:36 librem pulseaudio[772]: Playback too far ahead (1138), drop source 216

dec 04 18:54:37 librem pulseaudio[772]: Playback too far ahead (76176), drop source 14624

dec 04 18:54:38 librem pulseaudio[772]: Playback too far ahead (32204), drop source 6180

dec 04 18:54:39 librem pulseaudio[772]: Playback too far ahead (8162), drop source 1564

dec 04 18:54:40 librem pulseaudio[772]: Playback too far ahead (7195), drop source 1380

dec 04 18:54:41 librem pulseaudio[772]: Playback too far ahead (7789), drop source 1492

dec 04 18:54:42 librem pulseaudio[772]: Playback too far ahead (7978), drop source 1528

dec 04 18:54:43 librem pulseaudio[772]: Playback too far ahead (8395), drop source 1608

dec 04 18:54:44 librem pulseaudio[772]: Playback too far ahead (7814), drop source 1500

dec 04 18:54:45 librem pulseaudio[772]: Playback too far ahead (6930), drop source 1328

dec 04 18:54:46 librem pulseaudio[772]: Playback too far ahead (6205), drop source 1188

dec 04 18:54:47 librem pulseaudio[772]: Playback too far ahead (8064), drop source 1548

dec 04 18:54:48 librem pulseaudio[772]: Playback too far ahead (9949), drop source 1908

dec 04 18:54:49 librem pulseaudio[772]: Playback too far ahead (10102), drop source 1936

dec 04 18:54:50 librem pulseaudio[772]: Playback too far ahead (10147), drop source 1948

dec 04 18:54:51 librem pulseaudio[772]: Playback too far ahead (9986), drop source 1916

dec 04 18:54:52 librem pulseaudio[772]: Playback too far ahead (10082), drop source 1932

dec 04 18:54:53 librem pulseaudio[772]: Playback too far ahead (9918), drop source 1904

Logs 3 - ModemManager Errors

Scrolling through the logs of all my testing, I also see quite a few of these warnings passing by:


dec 04 19:07:56 librem gnome-calls[1165]: Error starting outgoing call ModemManager call to `<PHONE NUMBER>': GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't start the call: Unhandled response '$GNGNS,,,,,, <TRUNCATED>

dec 04 19:07:54 librem ModemManager[593]: <info> [modem1/call2] call state changed: dialing -> terminated (unknown)

dec 04 19:07:56 librem gnome-calls[1165]: Error starting outgoing call ModemManager call to `<PHONE NUMBER>': GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't start the call: Unhandled response '$GNGNS,,,,,, <TRUNCATED>

dec 04 19:07:54 librem ModemManager[593]: <info> [modem1/call2] call state changed: unknown -> dialing (outgoing-started)

dec 04 19:07:54 librem ModemManager[593]: <info> [modem1/call2] user request to start call

I didn’t post the entire response, as I’m not sure if it contains private information or not, but it’s a fairly long response that seems to be delimited by markers such as $GPVTG, $GNGNS, and so on. It seems that it’s not able to parse some response sent back by the operator or something, but I don’t know enough about the subject to be sure.

Logs 4 - Errors During Idle

Whilst leaving the phone idle for over an hour, with cellular reception on, I see large amounts of the following errors logged:


dec 04 20:26:11 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:26:11 librem kernel: dwc3 38100000.usb: failed to send remote wakeup

dec 04 20:26:10 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:26:04 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:25:59 librem kernel: dwc3 38100000.usb: failed to send remote wakeup

dec 04 20:25:59 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:25:54 librem kernel: dwc3 38100000.usb: failed to send remote wakeup

dec 04 20:25:53 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:25:48 librem kernel: dwc3 38100000.usb: failed to send remote wakeup

dec 04 20:25:47 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:25:42 librem kernel: dwc3 38100000.usb: failed to send remote wakeup

dec 04 20:25:42 librem kernel: dwc3 38100000.usb: request 00000000c8eeeff1 was not queued to ep1in

dec 04 20:25:36 librem kernel: dwc3 38100000.usb: request 00000000607799dd was not queued to ep1in

They’re usually about 10 seconds apart.

dos · December 5, 2021, 3:17am

This sounds like something is enabling GPS reporting from the modem (which won’t work because there’s no antenna connected), which somehow manages to confuse ModemManager. I don’t think I’ve ever seen that happening to me; did you modify geoclue configuration or anything related? Installed some apps that may request location? I’ll take a closer look, but AFAIK the stock configuration should handle that.

That happens when modem state as reported by ModemManager doesn’t match the modem’s actual state, so when wys tries to stream audio to the modem thinking that it’s going to receive it, but the modem isn’t actually listening, PulseAudio ends up buffering it. We should get that buffer severely limited at some point, but ultimately this is just a symptom of another issue deeper in the stack.

5890238590 · December 5, 2021, 1:21pm

Thanks for the quick response!

The installation is mostly stock Byzantium - I only did some rudimentary steps such as changing the LUKS disk encryption password, my account PIN, settings in the configuration screen, and set up OpenSSH for access; I didn’t install any actual applications yet, but I did try to use the shipped GNOME maps with geolocation and 4G data enabled, which is the only thing I can think of that might be triggering this.

I see, that explains the audio being sent at a later point in time. I’m also inclined to think that the root cause is another issue, such as ModemManager getting confused, which may again also be the cause of the UI getting confused.

If required, I can try to fetch more detailed journalctl logs of what exactly ModemManager is saying and try to reproduce a single such case. I’m also happy to file this in tickets on the appropriate projects on systems such as GitLab (I would have done so instead of posting this, but I don’t know enough about the stack to know which components are involved and where to report which problem, and thought perhaps I might be doing something wrong).

amarok · December 5, 2021, 3:11pm

Not saying its definitely the issue in your case, but this is exactly the kind of connection problem that will happen with a non-VoLTE phone (modem) being used in an area where the carrier has shut down or started limiting 3G bands.

5890238590 · December 5, 2021, 4:45pm

Not saying its definitely the issue in your case, but this is exactly the kind of connection problem that will happen with a non-VoLTE phone (modem) being used in an area where the carrier has shut down or started limiting 3G bands.

It is possible, but it would be strange, since, as mentioned, I restarted the modem afterwards and the same person could call me just fine, so it seemed more like the UI or modem got in a stuck state somewhere. (I don’t have logs on this one unfortunately, since it happened before the re-flash.)

If it were to be the issue, is there anything I can do to fix this, or is this perhaps a feature that is WIP?

amarok · December 5, 2021, 5:00pm

VoLTE on the L5 is still a work in progress, at least for the US modem. In the US, all the carriers will soon be shutting down their 3G spectrum in favor of 4G and 5G, meaning that any phones which carry calls and SMS over 3G, i.e. those without VoLTE (Voice over 4G LTE), will not be able to communicate.

Well, if there is a remnant of 2G around, they might get a signal. But the carriers have already started requiring VoLTE-capability in order to even activate a phone with them, so 2G is moot anyway. They’ve also already started turning off 3G in some areas of the country, so connection problems are starting to crop up.

Many other carriers in other countries have plans to sunset their 3G networks, too, with some already completed.

Purism team members have posted here about some initial success with VoLTE, so we can be hopeful.

tomoqv · December 7, 2021, 1:06pm

Which logs and how to get them should I provide when I run into problems with Calls?

I am having some of the issues mentioned above, but also that the phone gets so hot on phone calls that it is really uncomfortable to hold to the ear. Just now, after heating up, the audio from the calling party disappeared about 20 minutes into the call. He could still hear me. Restarting the phone did not fix the issue.

tomoqv · December 7, 2021, 1:10pm

Moreover, it is not uncommon for my L5 to ignore the proximity sensor and have my ear tap all kinds of things on the screen.

After restarting the phone, the only audio output unit available in settings is “Speaker…”, which seems to be the loudspeaker unit of the phone. Built in speaker is not available. If I plug in the headset, I also get “Headph…”, but the dropdown list won’t let me choose “Speaker…”.

Edit: I am getting loads of these in journalctl:
dec 07 14:01:13 pureos kernel: redpine_91x: Packet Dropped as Key ID not matched with both current and previous Key ID
What does that mean?

irvinewade · December 8, 2021, 12:49am

Ignore it. We all get those messages. I don’t know what they mean but it seems to relate to WiFi.

If it is actually causing you a problem and you can, in the context, kill the WiFi then that should get rid of the messages.

5890238590 · December 12, 2021, 6:19pm

I wanted to report on similar issues which I encountered yesterday, to see if I need to report this upstream somewhere, or if this is a problem with the Librem phone specifically (i.e. because it ships older versions of e.g. ModemManager).

Yesterday I used the dial pad in GNOME calls to place a call, and it, after showing the calling UI for a fraction of a second, bailed me back to my contacts overview. Analyzing the logs gave me the following messages:

dec 11 18:19:59 gnome-calls[1146]: Error starting outgoing call ModemManager call to `<CENSORED>': GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't start the call: Unhandled response '$GNGNS<CENSORED>>'
dec 11 18:19:59 ModemManager[710]: <info>  [modem3/call0] call state changed: dialing -> terminated (unknown)
dec 11 18:19:59 ModemManager[710]: <warn>  [modem3/call0] couldn't start call: Couldn't start the call: Unhandled response '$GNGNS...<CENSORED>'
dec 11 18:19:58 gsd-color[973]: unable to get EDID for xrandr-DSI-1: unable to get EDID for output
dec 11 18:19:58 ModemManager[710]: <info>  [modem3/call0] call state changed: unknown -> dialing (outgoing-started)

I censored the responses because they might contain private information (I don’t know enough about this). One of the problems is gnome-calls not properly handling this error, but more important is that ModemManager breaks down on trying to place a call. Is this also related to VoLTe or similar? This was placing a basic call to a standard land line number in Europe - in other words, it’s about as basic as it can get.

I also doubt this is related to GPS, unless my provider is doing something wonky (it’s one of the largest providers available here, though), this is literally all that is in my logs between placing the call and the UI breaking down, so it seems as if ModemManager simply cannot properly process the necessary basic responses. I did notice that ModemManager is an old version on the Librem Phone (1.14, I think), so I’m hesitant to report it upstream as it might already be fixed in later versions.

Can anyone from Purism advise as to the next steps to take? Should I wait for a ModemManager update, or report it upstream anyway? Should I contact Purism support? Basic calls working is critical to me since I use the phone professionally.

Zimmy · December 12, 2021, 7:51pm

This was message was just reposted by @agx (Guido Gunther) on his social librem feed:

https://fosstodon.org/interact/107435120253934338

It seems that VoLTE on the L5 is working on T-mobile’s network. Looking forward to more details…