Remove systemd service for Fcc unlock in "ubuntu-oem" branch

[nitinexclusively]

Hello @binli ,

I think , we don't need systemd service for FCC unlock APP .
FCC unlock will be executed by ModemManager i.e ModemManager will execute script
ModemManager will call scripts in below path based on Modem and this script will call FCC unlock binary .
/usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d/14c3:4d75

So , we dont need to create FCC unlock as systemd service . Its OK to keep configservice as systemd

So, I think ,we need to modify like below:

Remove below files:

• lenovo-fccunlock.modaliases
• lenovo-fccunlock.postinst
• lenovo-fccunlock.postrm
• lenovo-fccunlock.service

Remove fcc unlock service information from below files:

• rules
• lenovo-fccunlock.install

Can you please check it and let me know your comment .
Thanks

[binli]

Hi @nitinexclusively ,

I recheck it again. The fccunlock.service is only called by ModemManager, by default, it has option '--no-enable --no-start' in debian/rules, and the MM's script just start this service directly while not call /opt/fcc_lenovo/DPR_Fcc_unlock_service directly.

dh_installsystemd -p lenovo-fccunlock lenovo-fccunlock.service --no-enable --no-start

cat debian/mm-hook

#!/bin/bash

systemctl start lenovo-fccunlock
exit $?

[binli]

binli@654b069

I tried to use the new package, but the wwan didn't work any more.

I'm not sure what's the story of this service file, currently I prefer to use the service file, and focus on the other issues.

[binli]

debian/lenovo-fccunlock.postinst and debian/lenovo-fccunlock.posrm are still needed, it would enable/disable drop-in service file for MM.

[binli]

lenovo-fccunlock.modaliases is used for matching the supported platform.

[binli]

I found there are a lot apparmor error after removing the service file.

Oct 22 08:12:45 Thames-3 audit[2662]: AVC apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 kernel: audit: type=1400 audit(1729599165.620:74): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 audit[2664]: AVC apparmor="DENIED" operation="exec" class="file" info="no new privs" error=-1 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="/usr/bin/lspci" pid=2664 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="/opt/fcc_lenovo/DPR_Fcc_unlock_service///usr/bin/lspci"
Oct 22 08:12:45 Thames-3 kernel: audit: type=1400 audit(1729599165.621:75): apparmor="DENIED" operation="exec" class="file" info="no new privs" error=-1 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="/usr/bin/lspci" pid=2664 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="/opt/fcc_lenovo/DPR_Fcc_unlock_service///usr/bin/lspci"
Oct 22 08:12:45 Thames-3 audit[2662]: AVC apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 kernel: audit: type=1400 audit(1729599165.622:76): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 audit[2666]: AVC apparmor="DENIED" operation="exec" class="file" profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="/usr/bin/lsusb" pid=2666 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 audit[2662]: AVC apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 kernel: audit: type=1400 audit(1729599165.623:77): apparmor="DENIED" operation="exec" class="file" profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="/usr/bin/lsusb" pid=2666 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 kernel: audit: type=1400 audit(1729599165.623:78): apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Oct 22 08:12:45 Thames-3 audit[2662]: AVC apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

[nitinexclusively]

@binli Here is the flow of FCC unlock (this behavior works fine in Main branch)

1. Debian package should copy scripts and binaries in their respective path
2. When SIM is inserted and MM is ready . MM will directly call script from below path:
   /usr/lib/x86_64-linux-gnu/ModemManager/fcc-unlock.d/
3. FCC unlock binary is executed from the above script.

Can you please share below output after rebooting machine :

• mmcli -m any
• cat /var/log/syslog | grep -i dpr_fcc_unlock
• cat /var/log/syslog | grep -i configservice

Thanks

[binli]

Here are the logs, tested on Thames-3(SVT) with the new commit which removed systemd service.
The wwan doesn't work any more, it will connect and disconnect all the time, even I restart ModemManager.

binli@993aea4

mmcli.log
mm.log
fcc.log
cfg.log

[binli]

mm.webm

[nitinexclusively]

@binli As per log fcc.log FCC unlock is not issue . I can see because of AppArmor issue , its not executed .
Just in case - I have tried LTS version using package from main branch , it works fine.

[binli]

#31
I found the above change affected fccunlock, we need go through all the resource which 'ps' accessed and add them all into apparmor rules.

[nitinexclusively]

@binli Do you have any update regarding this issue ?

We have tested OEM image and only issue we faced is sometime , we need to perform "systemctl restart ModemManager" after rebooting.
However, this is fixed by modifying service file i.e ExecStartPre=/bin/sleep 90 as attached
lenovo-cfgservice.zip
Can you please try this.
Thanks

[binli]

@nitinexclusively I had Internal Conference last week, and this week is a little busy, I spent sometime on the apparmor rules, I will continue to go through the apparmor rules and packing the v2.1.3, I will keep you updated if there is any progress, thanks!

[binli]

@nitinexclusively I made a merge request for removing this service, please help review it, thanks!

[nitinexclusively]

@binli Thanks, Changes looks OK to me . i will merge it . I hope you had already tested it using OEM image ?
Also , Can you please test if suspend (system going to suspend mode ) is working OK or not using OEM image when WWAN is connected ?
Thanks

[binli]

@nitinexclusively I will make another commit to fix permission issue from apparmor.

[binli]

I just used the same apparmor rules in 2.1.2, I found the 2.1.3 will call sendmsg, the DPR_Fcc_unlock_service send message to ModemManager to load the device hook? And what's the way in 2.1.2? @nitinexclusively

apparmor="DENIED" operation="sendmsg" class="file" info="Failed name lookup - disconnected path" error=-13 profile="/opt/fcc_lenovo/DPR_Fcc_unlock_service" name="run/systemd/journal/dev-log" pid=2662 comm="DPR_Fcc_unlock_" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

[binli]

I use the systemd service again, then the sendmsg errors are gone, it might be related to run the DPR_Fcc_unlock_service directly, so currently I prefer to keep this service file. It did not affect the function at least.

[binli]

@binli Do you have any update regarding this issue ?

We have tested OEM image and only issue we faced is sometime , we need to perform "systemctl restart ModemManager" after rebooting. However, this is fixed by modifying service file i.e ExecStartPre=/bin/sleep 90 as attached lenovo-cfgservice.zip Can you please try this. Thanks

90 seconds is too long, the systemd will kill it as timeout. I used 30 seconds, it seems good, wwan could be connected after boot-up.
But it's just a workaround, it would be better to find the root cause.

[nitinexclusively]

I use the systemd service again, then the sendmsg errors are gone, it might be related to run the DPR_Fcc_unlock_service directly, so currently I prefer to keep this service file. It did not affect the function at least.

Ok but we need to analyse it more . Can you try by deleting library from /opt/fcc_lenovo/lib/ folder this will confirm sendmsg is passed from library .
Also , I am not sure but can't we directly grant access to sendmsg for this binary .

@binli Do you have any update regarding this issue ?
We have tested OEM image and only issue we faced is sometime , we need to perform "systemctl restart ModemManager" after rebooting. However, this is fixed by modifying service file i.e ExecStartPre=/bin/sleep 90 as attached lenovo-cfgservice.zip Can you please try this. Thanks

90 seconds is too long, the systemd will kill it as timeout. I used 30 seconds, it seems good, wwan could be connected after boot-up. But it's just a workaround, it would be better to find the root cause.

Thanks for checking this . Yes , we have also tested it and will change it to 30 seconds .
Issue seems to be due to device port /dev/wwan0mibim0 occupancy . Both MM and SAR config APP uses this device port . So , we should wait for ModemManager to be loaded successfully before executing SAR config App .
So , i think its correct behavior now.

Thank you !

[binli]

I found the mmcli was blocked by apparmor, I unconfined the mmcli, then I don't need the sleep method any more.

[nitinexclusively]

I found the mmcli was blocked by apparmor, I unconfined the mmcli, then I don't need the sleep method any more.

Ok , in that case , can you please send merge request , if needed.
Thank you !

[binli]

The fix of apparmor rules is in ubuntu-oem branch, thanks!
#37